Re: Provider to Provider Messaging
The HL7 claims attachment is embedded within the 275 (Additional Information to support a Health Care Claim or Encounter) in a BIN (Binary) Segment; it's as if it was a separate file altogether, and the HL7 delimiters have nothing to do with those used by the enveloping X12 transaction. The HL7 message is just tagging along for the ride with the 275, and just ends up wherever the 275 does; I don't believe the claims attachment provides us with any insights into addressing and routing that might be useful for inter-entity transfer of HL7 messages. William J. Kammerer Novannet, LLC. Columbus, US-OH 43221-3859 +1 (614) 487-0320 - Original Message - From: Dave Minch [EMAIL PROTECTED] To: 'William J. Kammerer' [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Tuesday, 27 August, 2002 02:37 PM Subject: RE: Provider to Provider Messaging HL7 was originally designed as a standard protocol for exchange of financial and clinical data within an enterprise. The purpose was to allow disparate application vendors within a facility to acquire and send data into/out of their applications with a minimum of custom programming. As Wes has pointed out, HL7 is very popular in small and large facilities alike, and I know of no healthcare clinical systems vendors that don't support HL7. V3 (the XML version) has been well received so far, and should start making inroads into the older v2.3.1 V2.4 implementations. Even large organizations like Kaiser have standardized their internal interfaces around HL7. We have been expecting HL7 messages to be a part of the additional information transaction (275), and Wes has confirmed that it is, indeed, featured prominently. The interesting question will be how the MSH will work within the ST. The MSH describes, among other things, the separators that are used in the message, and can allow a much wider range than X12... As to how HL7 will fit into the ebXML-CPP, I don't anticipate any problems as long as we're discussing V3 beyond; I'm just no sure how we can fit in the older versions. What does concern me is the different perspective of the messaging itself. With X12 we're talking about entity-to-entity EDI messaging where the entities are bound only by external business relationships, and the transactions are intended to be batched. HL7, on the other hand, has always had as its domain inter-entity, and entity-to-entity exchanges where the entities are more closely associated (mostly, under the same umbrella corporation), and the messaging is intended to be asynchronous and near-real-time. While the difference may be subtle, is nevertheless important because of how message management is done. With HL7, there is usually an external interface engine (think super translator) of some kind that not only translates / transmits / receives messages, but also manages the links queues the messages travel on. 997s, TA1s and 824s don't exist, per se, in HL7 land, because the interface engine takes care of much of the transaction validation and acknowledgement. The closest HL7 equivalent is the application ACK. HL7 messages, by definition, contain discrete sets of financial or clinical data (within one MSH) from specific applications, and within a single MSH, all of the data goes to a single receiver (or the same message can be cloned to go to many receivers within the interface engine, or can be cloned and sent directly by the originator). There is no facility within HL7 for a single message to have different parts some of which go to one receiver, and some which go to another. The BHS is the closest thing to a GS, and while the FHS is the rough equivalent to an ISA, I'm actually not aware of anyone who uses it. Both the BHS and FHS have only sending application and facility, and receiving application and facility to contain identifiers (same as the MSH), and there are no standards for how those are used. I'll be very interested to see the treatment of HL7 within the 275 - it should help answer a lot of questions. Dave Minch TCS Project Manager John Muir / Mt. Diablo Health System Walnut Creek, CA (925) 941-2240 discussions on this listserv therefore represent the views of the individual participants, and do not necessarily represent the views of the WEDI Board of Directors nor WEDI SNIP. If you wish to receive an official opinion, post your question to the WEDI SNIP Issues Database at http://snip.wedi.org/tracking/. Posting of advertisements or other commercial use of this listserv is specifically prohibited.
Authentication and Access to the Healthcare CPP Registry
Some discussion is going on in the background among the Overview authors about Authentication and access to the Healthcare CPP Registry.The term enroll was being bandied about - this time in the context of enrolling for access to the Registry. I would use the term enroll in a more restricted sense: only when talking about bi-lateral (actually, usually one-sided) negotiation between two parties before actual trading commences. Just because someone is entered in the Healthcare CPP registry, it doesn't necessarily mean payers want to take EDI interchanges from him: payers will probably demand that the provider be enrolled (i.e., fill out a bunch of forms). Keep in mind that a vocal minority really wants Open-EDI (i.e., they interpret the TCS rule to say payers have to take in anyone's standard transactions, enrolled or not). Pretty much, I'd let anyone register their CPP and search others' CPPs in the CPP Registry as long as they had a certificate that said they had something to do with Healthcare. That something to do with Healthcare is hard to define - and even harder to express in X.509 certificates! Is it based on who signs (e.g., in effect the AMA, NCPDP or NAIC) the certificate, or which extensions are added, etc.? This has to be figured out; and since the problem is kind of unique to Healthcare, it will probably have to be done in the ID Routing group - or even some AFEHCT group. Any ideas? Do we have any PKI or X.509 experts out there? William J. Kammerer Novannet, LLC. Columbus, US-OH 43221-3859 +1 (614) 487-0320 discussions on this listserv therefore represent the views of the individual participants, and do not necessarily represent the views of the WEDI Board of Directors nor WEDI SNIP. If you wish to receive an official opinion, post your question to the WEDI SNIP Issues Database at http://snip.wedi.org/tracking/. Posting of advertisements or other commercial use of this listserv is specifically prohibited.
Re: Trading Partner Agreements
Bruce: When we discuss things here, please work under the assumption of an environment conforming to the HIPAA TCS and Privacy rules, more or less as they are promulgated today. It would be too clumsy to preface everything we say with If HIPAA TCS were still the law and compliance were required... Or, if you prefer using the Buckeye subjunctive, something like If it *wuz* the law... Rest assured that if the HIPAA TCS Rule were abandoned, cancelled, de-promulgated, de-enacted, obliterated - or whatever - that probably a lot of things we've discussed (and that will find their way into the recommendations) won't have any relevance, let alone the force of law. Now having disposed of your red herring, can we start over again? Please tell us (if the HIPAA TCS law *wuz* in effect) why you believe Christine has to wait around for paper TPAs and other enrollment hurdles to be completed before she sends HIPAA compliant transactions to a payer? William J. Kammerer Novannet, LLC. Columbus, US-OH 43221-3859 +1 (614) 487-0320 - Original Message - From: Bruce T LeGrand [EMAIL PROTECTED] To: WEDi/SNIP ID Routing [EMAIL PROTECTED] Sent: Wednesday, 17 July, 2002 11:14 AM Subject: RE:Trading Partner Agreements I actually spoke off-line to Christine about this yesterday, and I tried not to answer this morning, but just could not shut up. A little bit naive was Christine's reference to a board member's suggestion, and for good reason. As those of us in health care know, arguing with a payer about your claim format, especially when you don't yet have the force of law behind you, is only likely to make you miss payroll. --( Forwarded letter 1 follows ) Date: Tue, 16 Jul 2002 21:38:31 -0400 To: WEDi/SNIP.ID..Routing[routing]@wedi.org.comp From: William.J.Kammerer[wkammerer]@novannet.com.comp Sender: [EMAIL PROTECTED] Subject: Trading Partner Agreements Here's someone, Christine Jensen, who's not afraid of playing hardball. From her posting on the HIPAAlive discussion list, it does kind of sound like she's having a problem getting payers to say just what the heck they want from providers. Or maybe payers are just not ready yet to part with their companion guides. Or whatever. But what I find really interesting here is that Christine appears to be saying the heck with it, and wants to just send the standard transactions - and the payers had better be ready for them. She might still have the problem of finding out where to send the standard transactions - but that's something I hope we can help her with! Anyway, I don't think Christine is being naïve: she obviously has figured out what to place in the standard transactions, so why can't payers figure out how to read them? What is it in a TPA-cum-companion guide that helps either party in effecting the electronic relationship? William J. Kammerer Novannet, LLC. Columbus, US-OH 43221-3859 +1 (614) 487-0320 - Original Message - From: Jensen, Christine [EMAIL PROTECTED] Sent: Monday, 15 July, 2002 05:47 PM Subject: TCS: Trading Partner Agreements At this time none of my trading partners, health plans since we are a provider entity, have contacted us regarding trading partner agreements. I'm beginning to contact them since I don't want to hear for the first time about a TPA for a specific payer in July 2003. One of the executive staff members suggested giving potential trading partners a deadline; essentially telling them that if we don't hear from you regarding a TPA by 2/03 (or whatever) that we cannot enter into a TPA until some future date and that they will receive only the transaction as defined in the IG. There may be a bit of naiveté in that at suggestion, but I wondered if any providers were taking this kind of approach with trading partners and if so, what you experience has been. Thanks. Christine Jensen HIPAA Project Manager Denver Health 303.436.7942 discussions on this listserv therefore represent the views of the individual participants, and do not necessarily represent the views of the WEDI Board of Directors nor WEDI SNIP. If you wish to receive an official opinion, post your question to the WEDI SNIP Issues Database at http://snip.wedi.org/tracking/. Posting of advertisements or other commercial use of this listserv is specifically prohibited.
Trading Partner Agreements
Here's someone, Christine Jensen, who's not afraid of playing hardball. From her posting on the HIPAAlive discussion list, it does kind of sound like she's having a problem getting payers to say just what the heck they want from providers. Or maybe payers are just not ready yet to part with their companion guides. Or whatever. But what I find really interesting here is that Christine appears to be saying the heck with it, and wants to just send the standard transactions - and the payers had better be ready for them. She might still have the problem of finding out where to send the standard transactions - but that's something I hope we can help her with! Anyway, I don't think Christine is being naïve: she obviously has figured out what to place in the standard transactions, so why can't payers figure out how to read them? What is it in a TPA-cum-companion guide that helps either party in effecting the electronic relationship? William J. Kammerer Novannet, LLC. Columbus, US-OH 43221-3859 +1 (614) 487-0320 - Original Message - From: Jensen, Christine [EMAIL PROTECTED] Sent: Monday, 15 July, 2002 05:47 PM Subject: TCS: Trading Partner Agreements At this time none of my trading partners, health plans since we are a provider entity, have contacted us regarding trading partner agreements. I'm beginning to contact them since I don't want to hear for the first time about a TPA for a specific payer in July 2003. One of the executive staff members suggested giving potential trading partners a deadline; essentially telling them that if we don't hear from you regarding a TPA by 2/03 (or whatever) that we cannot enter into a TPA until some future date and that they will receive only the transaction as defined in the IG. There may be a bit of naiveté in that at suggestion, but I wondered if any providers were taking this kind of approach with trading partners and if so, what you experience has been. Thanks. Christine Jensen HIPAA Project Manager Denver Health 303.436.7942 discussions on this listserv therefore represent the views of the individual participants, and do not necessarily represent the views of the WEDI Board of Directors nor WEDI SNIP. If you wish to receive an official opinion, post your question to the WEDI SNIP Issues Database at http://snip.wedi.org/tracking/. Posting of advertisements or other commercial use of this listserv is specifically prohibited.
Re: CPP and COB [and companion guides]
Chris: We're in luck: there are already a number of standard formats out there for representing implementation guides (or IG-like companion guides) in a machine-readable format: (1) IMPDEF, a standard UN/EDIFACT message, at http://www.unece.org/trade/untdid, (2) gXML (Guideline XML) at http://www.oasis-open.org/cover/gxml.html, (3) SEF, the Standards Exchange Format, and (4) igML, the Implementation Guide Markup Language, at http://www.oasis-open.org/cover/igml.html You'll see that some discussion of representing HIPAA companion guides in IMPDEF has already ensued on the EDI-L mailing; see Rachel's posting from Wednesday (below). I've invited some of the proponents of these various formats to join us - perhaps they can educate us as to the advantages of their respective favorites! I don't care which of these is used, though I guess if we handled companion guides at all, I might have a slight preference for some kind of XML format - in order to be consistent with most of the other machine readable stuff pointed by the ebXML CPP electronic partner profile. The fact that I devised both SEF and igML - and practically invented the whole concept of machine-readable implementation guides over a decade ago (while I was a high school intern because I'm really, really young) - should not bias our selection. William J. Kammerer Novannet, LLC. Columbus, US-OH 43221-3859 +1 (614) 487-0320 - Original Message - From: Christopher J. Feahr, OD [EMAIL PROTECTED] To: 'WEDi/SNIP ID Routing' [EMAIL PROTECTED] Sent: Friday, 12 July, 2002 01:09 PM Subject: RE: CPP and COB [and companion guides] While the mission of this group is superficially about how to find and connect with partners, our discussion has consistently included consideration of how to find, connect, and do business with a partner. If the CPP will be the primary source of information about this, then it will definitely need to include or point to the details of various supported COB arrangements and any important companion guide info. To me, this seems no less critical than information about which transactions are supported, real-time vs. batch mode support, what sort of testing certification is required, etc. In phase one we want to at least identify all the CPP elements, but I think it's safe to assume that none of them will be machine-understandable in the first version. In the context of this workgroup, I would suggest that the legality of a companion guide element is irrelevant because all CG or IG elements are simply instructions. The goal of the CPP is to convey those and all other relevant instructions to the sender system. At the moment both guides are published exclusively in human readable form and everyone already has a copy of (or knows where to find) one of them, so only the supplemental CG instructions need to be referenced in the CPP. I'm not sure if anyone is currently working on a methodology for reducing all X12 IG instructions (whether the real or the companion variety) to a universal, machine readable XML format... but this would be a terrific idea. When IGs are machine-readable by compliant EDI manager applications, the maintainers of the CPP standard may wish to consider supplementing the pointer to the .pdf version of the CG with a group of XML instructions for auto-implementation of the CG instructions. SIDE BAR: There seems to be a general feeling today that CGs are bad because they move us away from true standardization... i.e., that CGs essentially spawn different flavors of the standard, leading to a world that looks like the one we are trying to get away from. As a provider, however (and I can't imagine that payors would feel differently) I could care less if there 100 or 1000 flavors of the 837-P... or even a unique one for every payor... provided there was an EASY/CHEAP/AUTOMATIC means for my system to discover and implement these business requirements. The requirements, themselves, do not have to be identical... only the method for implementing them. Same goes for the main IGs coming out of the X12 workgroups. As long as my billing system can suck new IGs in as easily as QuickBooks gobbles down and installs its updates every few weeks, then I could care less how complex they are or how may variants are supported. Payor-payor COB and companion guides might be examples of trading partner business requirements that are not fully fleshed out and agreed upon at the moment... in which case, the CPP should at least include a place-holder element to let the world know that we consider the CPP to be the ultimate home for this information. Regards, Chris Christopher J. Feahr, OD http://visiondatastandard.org [EMAIL PROTECTED] Cell/Pager: 707-529-2268 - Original Message - From: Rachel Foerster [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, 10 July, 2002 04:40 PM Subject: RE: [EDI-L] (Machine readable) Documentation of Jonathan, In spite of HIPAA's intent to standardize transaction set
Re: CPP and COB, was The use of Supplemental IG's
It seems that I've touched the third rail of HIPAA EDI: companion guides! Nonetheless, I have to reiterate again that companion guides are relevant to our work devising the CPP electronic trading partner profile. Peter Barry, our senior executive co-chair, had recently summarized on 05-30 two types of information entailed within the term EDI documentation: (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. And Peter is just repeating what was agreed upon when the Project Purpose scope was enlarged in early March. The scope was broadened [to allow us] to investigate ways not only of describing EDI addresses and attributes, but also mechanical representations of companion documents, in the formation of electronic Trading Partner Agreements. See Electronic Trading Partner Agreements - 3/5 Conversation with DWT (03-07) at http://www.mail-archive.com/routing%40wedi.org/msg00305.html. Now, if there were an objection to including machine readable companion guide information in the CPP at the time it was proposed, I must have missed it. There's no doubt that we can include in the CPP URL links to PDF or Word renditions of companion guides; but it was also our intention to investigate the possibility of reducing all or parts of these companion guides to XML'ized computer-readable information for the automatic configuration of maps. Larry Watkins has now informed us that the Transactions WG is already considering how to proceed with the issue of companion guides. That's good to hear, and some of us look forward to giving our input into the process. And ID Routing will use any results to guide the design of machine-readable companion document information within the CPP, which is clearly within our charter. But I suspect that by the time a careful evaluation of companion documents is made, we'll find out that there isn't much that can be made machine-readable. Most of what could have been made so - the things that go into an implementation guide like allowable delimiters, maximum repeat counts, acceptable code sets and the like - are probably illicit under HIPAA. We'll be left mostly with just textual information describing the adjudication process, which can be accommodated with URL pointers or text strings within the CPP. If my suspicions are correct, we've greatly reduced the amount of work we'll have to do. Further, I was very clear that the deepest we'll have to get into business analysis is to analyze what the HIPAA IG business models already say. We have no need to analyze Healthcare Administration from the ground-up for anything we're doing in ID Routing, as we can use what's already illustrated in the HIPAA IGs. This will probably be true of COB, an issue which has been repeatedly raised by Dave Minch over the course of months, but as recently as 06-13: I do have a further question for Bruce regarding development of trading agreements with other payers or third parties regarding COB claims. I'm trying to determine business requirements for payer--payer CPP elements, and i'm completely in the dark on how you do it today, or how you plan on forwarding COBs from standard transactions. I was only able to speculate, for Dave's benefit, on the symmetricity of CPPs - i.e., certainly payers will be able to discover other payers, just as providers and payers can discover each other. But that's only part of the answer, and probably something Dave already knew; I'm guessing that he really wanted to know how the CPP could advertise COB capabilities (to either providers or other payers). Unfortunately no one has deigned to come forth with any suggestions on his very pertinent question - if only to say it's not relevant because it's not a problem (which I think Kepa's Myth #233: COB claims might be saying). Telling us Dave's concern is out of scope is no answer whatsoever. I am asking that folks be extended the simple courtesy of letting them make their points and ask their questions. The co-chairs will decide what's within scope if distractions become a problem. William J. Kammerer Novannet, LLC. Columbus, US-OH 43221-3859 +1 (614) 487-0320 - Original Message - From: Rachel Foerster [EMAIL PROTECTED] To: 'WEDi/SNIP ID Routing' [EMAIL PROTECTED] Sent: Saturday, 06 July, 2002 01:28 PM Subject: RE: CPP and COB, was The use of Supplemental IG's William, I disagree with your interpretation of both the Electronic Transaction Final rule preamble and the HHS FAQ. First, the FAQ: You quoted the following: It is the health plan's decision
Re: digital certificates for access to CPP repository
Somehow, during the discussions of SPAM, anti-SPAM, Kennedy's bill, invitations to testing webinars, etc., we must have lost track of Chris Feahr's Registry authentication questions (below). Though this is indeed a big can of worms, fortunately we have folks on board who take special interest in such things - namely, our friends from US NIST. The OASIS ebXML Registry Technical Committee is also looking at these kinds of problems within its Security Services sub-committee. Maybe I can persuade Lisa Carnahan to take our requirements back to the Security Services people. Lisa is both a member of the OASIS ebXML Registry TC and of our group, and she has volunteered to be our Registry expert and co-author our working paper on Discovery of Healthcare CPPs. As an aside, Joe Rosmann has reminded me that there is an ebXML paper - the ebXML Registry Security Proposal - that gives some background on authentication, integrity and confidentiality with respect to the ebXML Registry; it's a little dated and rough, but still available at http://www.ebxml.org/specs/secREG.pdf. William J. Kammerer Novannet, LLC. Columbus, US-OH 43221-3859 +1 (614) 487-0320 - Original Message - From: Rachel Foerster [EMAIL PROTECTED] To: 'joe mcverry' [EMAIL PROTECTED]; 'WEDi/SNIP ID Routing' [EMAIL PROTECTED] Sent: Wednesday, 12 June, 2002 02:05 PM Subject: RE: digital certificates for access to CPP repository Joe, I understand. On the other hand, how else would you authentic an entity attempting to access a CPP reposistory? Furthermore, even assuming authentication, it's not at all clear to me that all entities would want their CPP info to be accessible to all parties accessing such a registry. This is a big can of worms and without any business case and business requirements, I believe that details of this type are much too premature. My concern is about the complexity that is ensuing as a result of these discussions and that I don't believe this (CPP/A, registry, etc.) is at all essential for health care to achieve compliance with HIPAA by the various drop-dead dates. Rachel -Original Message- From: joe mcverry [mailto:[EMAIL PROTECTED]] Sent: Tuesday, June 11, 2002 9:42 PM To: [EMAIL PROTECTED] Cc: 'WEDi/SNIP ID Routing' Subject: Re: digital certificates for access to CPP repository If authentication is in place then there should be no need to worry about digital certificates for access to CPP repository. - Original Message - From: William J. Kammerer [EMAIL PROTECTED] To: WEDi/SNIP ID Routing [EMAIL PROTECTED] Sent: Tuesday, 11 June, 2002 04:18 PM Subject: Re: digital certificates for access to CPP repository In the current version of the OASIS ebXML Registry specification, there are no provisions for confidentiality of Registry content. All content submitted to the Registry may be discovered and read by any client - which means anybody can find out that an entity is accessible via the registry, and where their CPP is located. On the other hand, only authorized submitters who have been authenticated using digital signatures can publish data in the registry. I am assuming that this means there exists a fine-grained mechanism whereby only the owner (or his agent) of information (e.g., the CPP) can submit or change his own information - as opposed to having to submit his information through a central authority for inclusion in the Registry. The CPP owner may have some means of obfuscating his own CPP, or parts thereof - revealing information only to authorized users- since the CPP itself could very well reside on his own server. Of course, I'm making a lot of assumptions. The details have to be ferreted out by the folks responsible for the working paper on Discovery of Healthcare CPPs: Peter Barry, Joe McVerry, and Dick Brooks! I think Joe only volunteered to look into UDDI. That leaves Peter and Dick to be the experts on the ebXML Registry. Maybe I could add Lisa Carnahan to the list, too. Does anyone else want to volunteer? William J. Kammerer Novannet, LLC. Columbus, US-OH 43221-3859 +1 (614) 487-0320 - Original Message - From: Christopher J. Feahr, OD [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, 10 June, 2002 06:31 PM Subject: digital certificates for access to CPP repository Dear Group: I would like to know if we have agreement (or could agree) on the following requirements regarding access to the CPP registry/repository data: 1. Allow any party to access the CPP registry, thus obtaining the URL that points to an entity's repository record(s). 2. Require a standard mechanism for entrance to the CPP repository record that somehow looks for a valid digital ID certificate If every CPP repository user was required to have a valid ID certificate somewhere (e.g., the AMA/Verisign deal that was mentioned once) then requiring that certificate as the entry pass to the repository would seem to be a way to keep the riff-raff out. I think we may still need ways
Re: The use of Supplemental IG's
The CPP Electronic Partner Profile will be much more attractive for payers to advertise their capabilities if it allows them to avoid as much up-front agreement with partners as possible. And if payers are prone to use CPPs (whether distributed privately by e-mail, or via the Healthcare CPP Registry), then every other player in Healthcare is likely to jump on board. The HIPAA 837 IG certainly does not mandate a prior agreement between the respective payers in the payer-to-payer COB (Coordination of Benefits) model: at the time the guide was written, the authors may not have imagined there was any other way for payers to communicate their willingness to perform COB. But now that we will have the CPP (legacy EDI extension) to advertise one's capabilities, there may not be any further need for messy bi-lateral contracts and agreements! For example, if a payer is willing to conduct the 269 Benefit Coordination Verification transaction with any other payer - perhaps assuming that payer has been certified - we can make the CPP capable of announcing this quite adequately. If a payer has advertised its ability to handle the 269 by enumerating the 269's Version / Release / Industry Identifier Code (e.g., 004040X122) as one of its supported transactions, and maybe included the relevant certification credentials, would that be enough to supplant the need for an explicit agreement between payers to do COB? Would it be enough to let providers know that the payer does COB? I'm assuming here that being able to do the 269 (with other payers) sufficiently implies the payer can do both COB models using the 837 as a COB request. Obviously, for any particular set of exchanges (between any one provider and the primary and secondary - or even tertiary - payers), there are a number of requirements that all have to be satisfied, including whether the provider itself can handle 835s. Even if the 269 isn't supported (by both payers), can we come up with some other alternate and elegant technique within the CPP to advertise COB capabilities? Further, is the mere ability to perform COB (which, through a little bit of work, I can't imagine the CPP couldn't handle) the same as saying one will do it with all comers? As an aside, companion guides are certainly relevant to our work in automating the linkages between providers and payers. Surely, objections to our specifications and recommendations will come from some payers who will say automation is impossible because they have special requirements that they must ensure the provider abides by. If these special requirements are illusory - and in contravention of the HIPAA regs - then we are better prepared to defend the CPP's lack of support for them. As an example, I don't want us to have to spend any time devising junk within the CPP for specifying the EDI delimiters that will accepted at a particular portal (i.e., EDI Address). William J. Kammerer Novannet, LLC. Columbus, US-OH 43221-3859 +1 (614) 487-0320 - Original Message - From: Rachel Foerster [EMAIL PROTECTED] To: 'WEDi/SNIP ID Routing' [EMAIL PROTECTED] Sent: Wednesday, 03 July, 2002 07:56 PM Subject: RE: The use of Supplemental IG's Irrespective of the points you raise below, the use, and/or proliferation of companion guides is not an issue that this work group can resolve. We've already identified that any CPP/A for health care just needs to be able to point to any companion guide(s). Endlessly debating the pros and cons of companion guides doesn't further the objectives of this group. Furthermore, your reference to the payer-to-payer COB model requires a prior agreement between the respective payers per the HIPAA 837 IG. I agree with Paul Weber that this discussion be moved to another WEDi SNIP work group's list. Rachel Foerster Principal Rachel Foerster Associates, Ltd. Professionals in EDI Electronic Commerce 39432 North Avenue Beach Park, IL 60099 Phone: 847-872-8070 Fax: 847-872-6860 http://www.rfa-edi.com -Original Message- From: William J. Kammerer [mailto:[EMAIL PROTECTED]] Sent: Wednesday, July 03, 2002 2:13 PM To: 'WEDi/SNIP ID Routing' Subject: Re: The use of Supplemental IG's A number of friction points have to be eliminated if we are to automatically hook up players in healthcare EDI. Unsolicited transactions from providers to payers (or even Payer-to-Payer, in the COB Model) would have to be supported without onerous up-front enrollment and coordination if our dreams of frictionless HIPAA e-commerce are to be realized. The discussion of companion guides arose out of the original thread entitled Non-participating/out of network providers. Heretofore, the lack of standard transactions may have been one of the primary reasons providers did not electronically engage infrequently encountered payers - as opposed to vague and unspecified financial reasons. Now that standard transactions are available, one-off implementation guides are no longer an impediment to the free
Re: The use of Supplemental IG's
Just out of curiosity, I went to the CMS web site to see if there were any Program Memos or Transmittals that had stuff about restricting inbound delimiters Sure enough, one of the first I picked out, Transmittal B-01-71 of NOVEMBER 8, 2001, says incoming 837 Professional transactions must utilize delimiters from the following list: , *, ~, ^, |, and: - exactly the situation I was bemoaning! What if another payer wants me to use the group, record and unit separators (hex 0x1D, 0x1E and 0x1F) only? Arbitrary special conditions for every payer! - precisely the problem standard transactions were meant to take care of! To top it off, I see where it also says Currency code (CUR02) must equal 'USA' - I take this to mean that CMS wants all amounts in U.S. Dollars, even if the billing provider is Canadian, for example. But this can't possibly make any sense since the currency code must be one of the internationally recognized codes from ISO 4217. USA is not among them - USD is the symbol for the U.S. Dollar. So would I have to make a special exception in my mapping for just CMS in order to use an invalid currency code - because that's just the way they do it. My data wouldn't even make it past a halfway self-respecting compliance analyzer using CMS' made-up codes. Or perhaps it was a typo? I have no problem with a companion guide that says what the payer is going to use from the particular standard transaction. But to reinvent the X12 and HIPAA IG syntax rules wholesale, as CMS is doing here, is clearly prohibited by the HIPAA TCS rule. I wouldn't be surprised if this kind of stuff becomes epidemic, and we're back to where we started from: one-off payer-specific IGs. For the purposes of our project, let's assume by October 2004 that we'll truly have standard IGs - and payers abiding by them! William J. Kammerer Novannet, LLC. Columbus, US-OH 43221-3859 +1 (614) 487-0320 - Original Message - From: Bruce T LeGrand [EMAIL PROTECTED] To: WEDi/SNIP ID Routing [EMAIL PROTECTED] Sent: Tuesday, 02 July, 2002 01:15 PM Subject: The use of Supplemental IG's SNIP But now individual EDI guidelines dictated by the payer are a thing of the past. As an aside, I do suspect that some payers will try to use companion guides in much the same way, thinking they're just renamed implementation guides. Except now, they will find that most of the (arbitrary) restrictions they place in these companion guides are unenforceable: I've even seen these guides say what particular X12 delimiters to use! A payer (or provider, or clearinghouse for that matter) must take a standard transaction as long as it conforms to the HIPAA IG: if the sender's delimiters are acceptable by the X12 application syntax rules and the HIPAA IG, the recipient should be the one doing the adapting. END Its not that I always want to be arguing against a position Mr. Kammerrer has taken, but I seem to find reasons all of the time. That said, payers are required to accept transactions. They are not required to adjudicate them, they are not required to do more that acknowledge the file with a 997. Thereafter, a status inquiry could be returned with a no record of this claim, and still meet the guidelines. Supplemental IG's are designed to ensure that this does not happen as often as it may otherwise. There are still business issues, not addressed adequately by the consensus process of the X12N group, yet, that require more specific information and usage. One payer that comes to mind immediately and is publishing a substantial supplemental IF is CMS, or more precisely Medicare Part A. If you think providers that file for part A claims are going to ignore this information, or this guide, you are sorely mistaken. I have cut a sample from a source: The Centers for Medicare Medicaid Service has issued updated guidelines for submitting Medicare Part A test claims in the ANSI X12N 837 Institutional format, which is required under the Health Insurance Portability and Accountability Act (HIPAA): The ANSI 837 v4010 Institutional Implementation Guide (IG) does not provide a place to report the start of care date for hospice outpatient claims. CMS has developed the following guidelines for submitting Outpatient Hospice claims via the 837 v4010 format: The 837 2300 loop Admission Date segment must be used to report the start of care date for outpatient hospice claims. Submit 0001 as a default hour and minute (HHMM) part of the admission date data element if the information is not available. To use the CR6 (Home Health Care Information) segment in the HIPAA 837 Institutional IG to report the start of care date for home health claims, all required segments must be used. CMS has developed the following guidelines for submitting Home Health claims via the 837 v4010 format: The 837 2300 loop Admission Date segment must be used to report the admission date/start of care date for home health claims. Submit 0001 as the default valued for the hour
Minutes of WEDi/SNIP ID Routing teleconference 2002-06-28
Minutes of the Overview Working Paper Teleconference, Friday, 2002-06-28 2:00-3:27 p.m. EDT (27 minutes over planned schedule). Attendees: John Barkley, US NIST Peter Barry, Peter T Barry Company Ron Bowron, Novell Lisa Carnahan, US NIST Chris Feahr, Vision Data Standards Council Dave Frenkel, GEFEG USA Lynne Gilbertson, NCPDP Mimi Hart, Iowa Health System William Kammerer, Novannet Zon Owen, Hawaii Medical Service Association Kim Peters, Humana Joe Rosmann Though we had originally intended to just discuss the Overview document, the teleconference grew in scope to cover a lot of stuff germane to the entire ID Routing project - as these things are wont to do. We reviewed our basic mission, official name (WEDI/SNIP ID, *Addressing* and Routing SIG), and proposed work products of this sub-working group. Our particular group is not joint with AFEHCT, but rather the Joint WEDI-AFEHCT Health Care Communications Security and Interoperability project (Interoperability) is a whole different animal with whom we will coordinate our findings. As a separate matter, Peter Barry is attempting to reenergize the moribund joint AFEHCT-WEDI project, but that shouldn't really affect anything we're doing in our very active ID Routing SWG. Lynne Gilbertson described the NCPDP issues in common with X12 HIPAA. It seems that one of the more pressing needs (outside of HIPAA) is in the Scripts protocol where doctors must send Rxs to pharmacies, and pharmacies in turn send refill and change requests to doctors; they need a standard way of discovering, etc. Pharmacy uses the NCPDP Provider Identification Number (the old National Association of Boards of Pharmacy Number) to identify pharmacies: each licensed pharmacy in the United States is eligible to be assigned a unique seven-digit number by NCPDP. A BIN Bank Identification Number (or ANSI IIN - a six-digit issuer identification number - as defined by ISO 7812) is used for identifying insurers. The pharmacy transactions are real time; the ANSI ASC X12 835 ERA is the remittance document used to report on pharmacy claims. Generally, the lines of communication between pharmacies and payers run the gamut from direct dial, clearinghouses, TCP/IP, all the way to leased line X.25. Lynne thinks she may be able to have the NCPDP routing requirements to share with us by 07-15. Kim interjected the interesting comment that his organization is using the DUNS for identifying providers (presumably until the NPI is available). We reaffirmed that major long-term benefits of this group's proposed specifications will be to small providers, but that significant near term benefits will accrue at the CH/VAN/Switch level. Ron spoke about the issues involved with the 3 As (authentication, authorization, and access) as they apply to accessing and submitting to the ebXML CPP registry component. We clarified that CPP Registry access is always via the Internet (specifically HTTP), even though the CPP itself can describe EDI portals or addresses supporting legacy telecommunication methods. Mimi, Chris, Ron, William, and Peter will collaborate on the Overview document. The purpose of the overview will be to describe the following on a conceptual or executive summary level: 1. name of the project and sponsoring organization 2. the mission and general description of proposed deliverables 3. business use-case; near term and long-term 4. general description of the registry and repository concepts and the term CPP (with general reference to OASIS and ebXML) 5. outline challenges/solutions in the area of Access, Authentication, and Authorization 6. briefly describe where EDI has been (present system of negotiating bilateral e-trading relationships) and where we believe it is heading in healthcare, both because of HIPAA and because of provider's need for real-time communication with many entities besides payors - and how the CPP supports that. 7. Outline immediate benefits (maybe this should be the lead) to the present middleman entities: CHs, VANs, and regional switches. Joe Rosmann has volunteered to review and edit the draft. We're aiming for a draft of the overview to be available to the ID Routing listserve subscribers by 07-26. Thanks to Chris Feahr for taking notes (and talking at the same time!). William J. Kammerer Novannet, LLC. Columbus, US-OH 43221-3859 +1 (614) 487-0320 discussions on this listserv therefore represent the views of the individual participants, and do not necessarily represent the views of the WEDI Board of Directors nor WEDI SNIP. If you wish to receive an official opinion, post your question to the WEDI SNIP Issues Database at http://snip.wedi.org/tracking/. Posting of advertisements or other commercial use of this listserv is specifically prohibited.
Evangelizing on the HIPAAlive mailing list.
Note the circumspect reference on the HIPAAlive Discussion List to what I presume is the WEDI/SNIP ID Routing project's Healthcare CPP Registry. William J. Kammerer Novannet, LLC. Columbus, US-OH 43221-3859 +1 (614) 487-0320 - Original Message - From: Bruce T LeGrand [EMAIL PROTECTED] To: HIPAAlive Discussion List [EMAIL PROTECTED] Sent: Friday, 28 June, 2002 10:43 AM Subject: [hipaalive] RE:RE:SECURITY -- New PKWare release has strong *** HIPAAlive! From Phoenix Health Systems/HIPAAdvisory.com *** SNIP Do you need a file compression program with encryption or an encryption program with file compression? END The answer to this is generic. It does not matter what an individual entity needs. It does matter what the whole varied conglomerate of the industry needs. And this need extends outside of the bounds of HIPAA. With that preface, I'd say we would need complete cross-architecture compatibility, especially if we are to attain the vision of the EDI enabled health care system I keep hearing about. In that scenario, any entity could discover the means to communicate with any other entity. Minimizing the potential for inconsistencies in the data flow would seem to be even more important than discovery. One happens once, the other continues for the duration of the relationship. Whether your product is encryption with supported compression, or compression with supported encryption, what is important is enabling the EDI exchange without demanding similar systems and architectures. discussions on this listserv therefore represent the views of the individual participants, and do not necessarily represent the views of the WEDI Board of Directors nor WEDI SNIP. If you wish to receive an official opinion, post your question to the WEDI SNIP Issues Database at http://snip.wedi.org/tracking/. Posting of advertisements or other commercial use of this listserv is specifically prohibited.
FYI: PayorID.com
PayorID is a web-based, standardized insurer name, claims address, phone, and electronics processing code source. PayorID is a master file of insurers, TPAs, HMOs, PPOs, and other MCOs. Integrate with PayorID to maintain your insurance master file. See http://www.payorid.com/, which seems to be a directory of over 25,000 Payors and 35,000 employer health plans. I've been told this has been around for about two years, but it's not known if anyone uses it. I wonder how the information is compiled. Generally, centrally managed for-profit directories (à la EDI Yellow Pages) don't seem to have successful track records. William J. Kammerer Novannet, LLC. Columbus, US-OH 43221-3859 +1 (614) 487-0320 discussions on this listserv therefore represent the views of the individual participants, and do not necessarily represent the views of the WEDI Board of Directors nor WEDI SNIP. If you wish to receive an official opinion, post your question to the WEDI SNIP Issues Database at http://snip.wedi.org/tracking/. Posting of advertisements or other commercial use of this listserv is specifically prohibited.
Re: Non-participating/out of network providers
If I've read providers, like Mimi Hart, correctly, they would indeed like to send electronic transactions to payers, even those with whom they do not participate. It's generally the payers who are resistant to taking in transactions from out-of-network providers - or at least providers who haven't been enrolled. Providers, especially hospitals, take in out-of-network patients all the time. Today, I assume that telephone calls, faxes and mail are the norm to determine will I get paid? The vision is that HIPAA standard electronic transactions will be the norm tomorrow. The issue of trust in cyberspace goes both ways: not only does the payer need to trust the provider, but the provider also needs to trust the payer. The payer wants to make sure that a transaction really came from the provider it purports to have come from, and - at the very least - that he provides services which make sense in the context of the claim (via certificates and Provider Taxonomy Codes); this the Healthcare CPP Registry and other technology can solve. The issue of whether the provider actually saw the patient, or really rendered the services stated, exists whether the claim is paper or electronic. On the other hand, the provider wants to make sure the eligibility inquiry goes to the real payer, and that the answers come back from the same place; we can solve this problem. The issue of payer viability - if that's what the provider is worried about - exists whether the eligibility response comes back on fax, phone or electronically. If it's a worrisome concern, go to A.M. Best for the answer. Obviously (or hopefully) a provider will not cut into a patient until the proper referrals are in hand; whether this can be done practically with the 278 is beyond me. Regardless, if standard transactions are available to the provider for communicating with the payer, why wouldn't he prefer to use them rather than the smile-and-dial rigmarole? Even payers are champing at the bit, wanting to conduct eligibility inquiries electronically with out-of-network or non-participating providers; take a look at the posting on the Transactions listserve entitled Re: Question: Rejecting a transaction (28 Aug 2001) at http://www.mail-archive.com/transactions@wedi.org/msg00075.html. In it Don Bechtel answers Jim Griffin, a payer, who really, really wants to do 270/271s with out-of-network providers, but at the same time wants to make sure he can reject providers whom he suspects of fraud: We are a national payer with contracted providers in every state, but only 50% or 60%/40% of our claims volume is with PPO providers, the rest is with providers where we have no agreements. Therefore the ability to perform a 270/271 is a great benefit for us, however the ability to reject such requests is also a business need. Similar situations could also exist with a claims status transaction. William J. Kammerer Novannet, LLC. Columbus, US-OH 43221-3859 +1 (614) 487-0320 - Original Message - From: Rachel Foerster [EMAIL PROTECTED] To: 'WEDi/SNIP ID Routing' [EMAIL PROTECTED] Sent: Sunday, 30 June, 2002 11:59 AM Subject: RE: Non-participating/out of network providers I'm not so sure that the issues of trust, a standard claim format, or anything other than will I/when will I get paid, is the major reason why a provider would not be willing to send a claim to a payer with which it does not participate. As for major procedures, such as cardiac procedures, services from a specialist, etc., I can't imagine any of these being performed by a provider without all of the appropriate referrals/authorizations, etc. Thus, the obstacle is not a technical one, but a financial one: if the provider is not participating in a given payer's network, then the concern is one of payment for health care services rendered, not what clearinghouse, what claim format, or what payer id to use. Therefore, if this is the typical case rather than a technical barrier, I would suggest that it might be worthwhile to move on to identifying other requirements/issues that would be within the realm of solution by an automated health care registry. Rachel Foerster discussions on this listserv therefore represent the views of the individual participants, and do not necessarily represent the views of the WEDI Board of Directors nor WEDI SNIP. If you wish to receive an official opinion, post your question to the WEDI SNIP Issues Database at http://snip.wedi.org/tracking/. Posting of advertisements or other commercial use of this listserv is specifically prohibited.
Re: Non-participating/out of network providers
With the advent of standard transactions, the marginal cost to large providers (or their billing service or clearinghouse agent) of using EDI with any new payer that comes along (i.e, their first encounter with a patient insured by that payer) will drop significantly. Regardless of the payer, the provider can now be reasonably sure the payer should understand any standard HIPAA transaction thrown at it, say an 837. Would it be possible that the cost of mapping to any particular payer's EDI guidelines was the real barrier to providers (institutional, at least) doing electronic billing on behalf of their patients in the past? But now individual EDI guidelines dictated by the payer are a thing of the past. As an aside, I do suspect that some payers will try to use companion guides in much the same way, thinking they're just renamed implementation guides. Except now, they will find that most of the (arbitrary) restrictions they place in these companion guides are unenforceable: I've even seen these guides say what particular X12 delimiters to use! A payer (or provider, or clearinghouse for that matter) must take a standard transaction as long as it conforms to the HIPAA IG: if the sender's delimiters are acceptable by the X12 application syntax rules and the HIPAA IG, the recipient should be the one doing the adapting. So now the only thing standing in the way of providers sending standard transactions to any old payer is the ugly, old, manual and onerous EDI enrollment process. As some of our correspondents have told us in the past, this is one area where clearinghouses have an advantage (over point to point). Generally, when a provider is signed up with a clearinghouse, she can send electronic transactions to any payer advertised by that clearinghouse, with the few exceptions of Medicare and some commercial payers. Kepa's and Marcallee's Clearinghouse Power-of-Attorney concept was meant to break down that remaining barrier. Presumably, most payers trust any provider to send electronic transactions to them via the clearinghouse for some reason: maybe they think the CH will scrape the viruses and cooties off the claims; who knows? Or perhaps the payers know that the CH will do some kind of front-end edits to make sure the claims are reasonably coherent. Certainly hospitals do courtesy billing with insurance companies they do not participate with; their ability to do eligibility inquiries, claims and COB electronically (as opposed to telephone calls, faxes and paper) should increase their operating efficiency. Unlike a physician provider, hospitals can't generally rely on the patient to pony up the cost of a heart transplant ahead of time; if they want the business, they have to help the patient navigate the insurance waters - even though the patient is ultimately responsible in a meta-physical sense. But the issue of identification and routing of transactions to payers from non-participating or out-of-network providers isn't one that requires too much more analysis and discussion. I suspect that it will eventually fall out of the bigger trust problem that comes along with the Healthcare CPP Registry. If payers know they can trust a provider - coming in out of the blue - they're more likely to commence electronic trading with them. And that trust might be conferred by digital IDs and signatures that, in effect, says the AMA knows the provider, or the ADA knows the dentist, or some accreditation body knows the hospital. Or even that any other known commercial insurance company knows the provider, thus building on a Web of trust concept. William J. Kammerer Novannet, LLC. Columbus, US-OH 43221-3859 +1 (614) 487-0320 discussions on this listserv therefore represent the views of the individual participants, and do not necessarily represent the views of the WEDI Board of Directors nor WEDI SNIP. If you wish to receive an official opinion, post your question to the WEDI SNIP Issues Database at http://snip.wedi.org/tracking/. Posting of advertisements or other commercial use of this listserv is specifically prohibited.
Re: Transactions Listserve: Unsolicited 277 in response to claim submissions
Fortunately, as the assistant co-chair waterboy, I get to decide what's in or out of scope, unless over-ruled by the senior executive co-chair, Peter Barry. I'm sure the Unsolicited 277 (277U) is a fine transaction, and I have no beef with it. I'm not interested at this time in discussing its innards or business functions; though if I were, I agree with Dominic that X12N TG2 WG5 would be the appropriate venue for discussion. No, instead, I'm interested in the law's ramifications on identification and routing. It looks like the law provides plenty of incentives for the use of EDI in both making claims and receiving Front-End Acknowledgments. The law doesn't say only if the provider has filed a bunch of paperwork with the payer. So, again, if a non-par provider needs to file a claim on behalf of the patient (which the law mandates), he may do it either with a paper claim or an 837. If he prefers an 837, to take advantage of NJ's more generous prompt-pay provisions with respect to EDI , how does he go about finding the electronic address of the payer? How does the payer know the provider's all set up to accept the 277U, or know where to send the acknowledgement? Is the provider locked into a CH arrangement in order to comply with the law? William J. Kammerer Novannet, LLC. Columbus, US-OH 43221-3859 +1 (614) 487-0320 - Original Message - From: Dominic Saroni [EMAIL PROTECTED] To: [EMAIL PROTECTED]; 'WEDi/SNIP ID Routing' [EMAIL PROTECTED] Sent: Wednesday, 26 June, 2002 11:39 PM Subject: RE: Transactions Listserve: Unsolicited 277 in response to claim submissions Rachel, I agree this thread should be moved to X12 Insurance TG2 WG5, where the v4040 277 Front-End Acknowledgment is being discussed. A quick note: NJ HINT does require a 277 Unsolicited v3070 standard to be replied to any claim with adjudication issues. This will be re-clarified in a NJ meeting next month. Please redirect any other questions to X12 Insurance TG2 WG5 or to me directly, if applicable. Dominic Saroni Associate Rachel Foerster Associates, Ltd. Professionals in EDI Electronic Commerce 39432 North Avenue Beach Park, IL 60099 Phone: 312-925-4525 Fax: 847-872-6860 http:/www.rfa-edi.com -Original Message- From: Rachel Foerster [mailto:[EMAIL PROTECTED]] Sent: Thursday, June 27, 2002 12:08 AM To: 'WEDi/SNIP ID Routing' Subject: RE: Transactions Listserve: Unsolicited 277 in response to claim submissions NJ's HINT law has been on their books for almost 2 years, so the requirement for providers to file claims on behalf of their patients is not new knowledge. And obviously NJ lawmakers didn't view it as nonsense. And, how did you make the leap from a provider being required to file a claim on behalf of the patient to an unsolicited 277 transaction. NJ HINT doesn't require it, nor does HIPAA. I trust you're not trying to take on the NJ legislature on their laws here, since that is most certainly out of scope. This is not an issue that WEDi SNIP Routing should be taking up. Out of scope! Rachel Rachel Foerster Principal Rachel Foerster Associates, Ltd. Professionals in EDI Electronic Commerce 39432 North Avenue Beach Park, IL 60099 Phone: 847-872-8070 Fax: 847-872-6860 http://www.rfa-edi.com -Original Message- From: William J. Kammerer [mailto:[EMAIL PROTECTED]] Sent: Wednesday, June 26, 2002 9:07 PM To: WEDi/SNIP ID Routing Subject: Transactions Listserve: Unsolicited 277 in response to claim submissions Here's a new one on me: Cynthia Korman told us on the WEDI/SNIP Transactions Listserve of NJ's HINT law. How is the payer going to know how to get the 277U back to the provider? And what's this nonsense about providers having to file claims on behalf of the patient? What if this is the first time the provider has ever dealt with the patient's insurance company? Is this another example of lawmakers writing rules which are almost impossible to implement? Will the Healthcare CPP Registry be of any help here? See the Health Information Electronic Data Interchange Technology Act (HINT) at http://www.state.nj.us/dobi/pn01_63.htm. Note especially: The Department also notes that the Act does not require providers to implement electronic systems for the processing of health care transactions. The Act merely states that 12 months after HINT becomes operative all health care providers shall file claims on behalf of patients unless the patient elects to personally file the claim. It should be noted, however, that the Act does provide incentives where providers file electronically. For instance, electronically filed claims must be paid in 30 days while paper claims must be paid in 40 days. Electronically filed claims must be acknowledged by payers within two days of receipt, and paper claims within 15 days of receipt. Any discussion? Yoo-hoo!! Anyone? Or is this too far off-topic from the usual run of anti-SPAM vigilantism? William J. Kammerer
Overview Working Paper Teleconference Friday 2:00-3:00 EDT 703-736-7290, Pin #6074647
We have a teleconference scheduled Friday (tomorrow, 2002-06-28) at 2:00-3:00 pm EDT to discuss the ID Routing Overview Working Paper. To participate, call 703-736-7290, and specify Pin #6074647. William J. Kammerer Novannet, LLC. Columbus, US-OH 43221-3859 +1 (614) 487-0320 discussions on this listserv therefore represent the views of the individual participants, and do not necessarily represent the views of the WEDI Board of Directors nor WEDI SNIP. If you wish to receive an official opinion, post your question to the WEDI SNIP Issues Database at http://snip.wedi.org/tracking/. Posting of advertisements or other commercial use of this listserv is specifically prohibited.
Re: Route through email and attach EDI files
Ronald: I don't think EDI would necessarily have looked any different if it had been devised in the TCP/IP world. Look at MIME: it's not any prettier. If XML had been available from the outset, maybe EDI would have used XML for its syntax. But you have to admit there's nothing inherent in the syntax of ANSI ASC X12 or UN/EDIFACT that keeps EDI from being a first-class Internet passenger. Peter Barry has suggested that payers with elaborate, web-based DDE services could allow providers to upload standard X12 interchanges right into a field in the DDE system, presumably wrapping EDI in MIME for an HTTP POST or something like that. And high tech messaging services like ebXML MS don't care whether they're carrying payloads of X12 or XML. The HIPAA standard transactions based on X12 and NCPDP already exist (and maybe new interactive ones based on the UN/EDIFACT syntax will be added into the mix later), and we can't do anything about it even if we wanted to. We should concentrate on devising recommendations for means of routing these packages safely, securely and reliably. If the next incarnation of HIPAA standard messages were based on XML schemas or core components, we'd still be left with the same problems we have today: how to get the claim to the payer, or the remittance to the provider. If we had a Healthcare CPP and Registry, they would work out-of-the-box for XML just as well as for EDI - trust me. EDI's market acceptance has nothing to do with the protocols it's built on: the syntax (ASC X12.5 and X12.6, ISO 9735 or XML) is the simple part - the semantics are difficult. FTP, SMTP, MIME and other Internet protocols have far fewer variables to deal with, and hence are simpler to interoperate. But I'll grant you one thing: if the (Healthcare) world were standardized on a single transport layer (TCP/IP), it would make things far less painful. For example, we wouldn't have much work left to do to customize the CPP DeliveryChannel, as it's already designed around TCP/IP protocols like HTTP and SMTP. And I certainly agree that there should be no need to duplicate the sender identification effort with another login process much like BBS's and FTP require. You should only have to logon once to your own ISP, VAN or CH, and not duplicate that process for every payer you might conceivably access; that's the whole point of eliminating payer-centric mailboxes. As an aside, Open Source isn't the answer to all that ails us. Most of us don't still live at home with Mom, and therefore we have to charge for our labor. Open Source is often a model which works well for hardware manufacturers (i.e., using Open Source infrastructure software to encourage development for their platform), but I've never seen it applied to e-commerce applications. William J. Kammerer Novannet, LLC. Columbus, US-OH 43221-3859 +1 (614) 487-0320 - Original Message - From: Ronald Bowron [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, 21 June, 2002 01:39 PM Subject: Re: Route through email and attach EDI files As a long time fan of efficient transfer of business data (i.e. EDI vs. XML), I've often wondered why the Open Source community has never taken EDI under it's wing like they have other services (FTP, SMTP, Telnet). I guess the market wasn't there. Anyway, to keep in line with our efforts, I've always wondered what EDI would be like if it were developed in the TCP/IP world vs. the legacy BBS (async protocols) VAN (SNA/Bysnc protocols) world. I've also believed that part of the reason other application or file transfer protocols (FTP, SMTP, XML) seem to gain wider acceptance more rapidly than EDI is simply that they've standardized on a single transport layer (TCP/IP). So I ponder on this as I look out over the issues raised in this forum. Can a standard interface be developed that would work much like SMTP but without all the overhead of another addressing schema? Imagine if an EDI client application were built in the open source community (much like SendMail), that when given the EDI filename, would access the ISA Header and GS segment, use that information to locate (Either via ACL, LDAP, DSML, ebXML/CPP) in an ID Repository the proper destination and communication method and protocol (of course today, the TCP/IP protocol would be nice). The EDI Server (much like an SMTP Server) would acknowledge the EDI Client request, (assuming TCP/IP) establish a VPN or SSL channel (for encryption purposes) and validate digital certificates, and then receive the ISA header. Verify the Sender/Receiver information, and request the GS segment. From there, the GS segment would be used by the EDI Server to set the Functional processing of the transactions (Realtime/Fast-Batch/Batch) and send the I/O stream on its way to the appropriate application service queues or simply stored as a file. So basically, all the necessary information to login the user, determine what they are needing to do is in the ISA and GS segments
Re: I'm not sure we really need exotic business models at all
Rachel: Pretend we're all from the Show-Me State. Why don't you rustle up a model describing the situation of routing re-priced claims that I illustrated in my third paragraph? Throw in all the stick figures you want. William J. Kammerer Novannet, LLC. Columbus, US-OH 43221-3859 +1 (614) 487-0320 - Original Message - From: Rachel Foerster [EMAIL PROTECTED] To: 'WEDi/SNIP ID Routing' [EMAIL PROTECTED] Sent: Tuesday, 25 June, 2002 11:44 AM Subject: RE: I'm not sure we really need exotic business models at all William, I don't think that Dave was advocating exotic business modelsjust recognizing that one needs to have a starting point for developing a roadmap to another point. For example, if you were going to put an addition on your home you most likely would start with a model (the blueprint) of what your home is today - how it's configured, doors, windows, rooms, etc. With that model in hand, it's much easier to design the addition and to get it right the first time. This is neither exotic nor unnecessaryit's just plain common sense that you document (via a model) what you're starting out with and then document (model) what your end point is so that you can at least know if you get to where you wanted to go. Rachel -Original Message- From: William J. Kammerer [mailto:[EMAIL PROTECTED]] Sent: Tuesday, June 25, 2002 10:33 AM To: WEDi/SNIP ID Routing Subject: I'm not sure we really need exotic business models at all Dave: I'm not sure we really need exotic business models at all. Our project scope is limited to devising recommendations which effect the identification and routing (safely, securely and reliably, I might add) of complete X12 interchanges. Whether claims, eligibility requests, claim attachments, status requests or responses, or remittances are included in those interchanges is probably of little matter to us: we're only concerned with routing standard transactions hither and yon. And the parties are (or should be) symmetric: everyone will have the same capabilities to define EDI addresses, supported transactions, etc., etc. It should matter little whether the CPP belongs to a payer, a TPA, a billing service, a re-pricer, a clearinghouse, a hospital or even a doctor. And it shouldn't make any difference if a payer wants to send a 269 to another payer, or a provider wants to make a claim: the rules for navigating and interpreting the CPP Electronic Partner Profile will be the same. The only difference between individual CPPs is that a large payer or CH would probably exercise more of the features available to everyone: multiple DeliveryChannels (with finer breakdown of transaction sets per DeliveryChannel - e.g., to support real-time vs. batch), more supported transactions, and so on. We do have to examine a number of business use cases simply to devise capabilities. For example, maybe a payer has a number of plans, some of which need to have claims against them go to a re-pricer before being forwarded on to the payer. Since plans handled by the same payer have to be treated differently, it stands to reason that the creator of the CPP (generally the payer) has to have some means of distinguishing between plans for some functional groups. Perhaps claims (set apart by their functional group IDs) for a set of plans are directed to the DeliveryChannel (or EDI Address) describing a portal at the re-pricer. The provider submitting a claim for one of those plans would be none the wiser (unless he reviewed the copious free-form comments the payer included in the CPP XML document!) that his 837 was being shunted off to the payer's business associate, the re-pricer - directly (using an explicit definition of the re-pricer's portal) or indirectly (by referring to the re-pricer's CPP). I'm not pretending to know any of this stuff - everything I know about what goes where, and who does what, came mostly from some of your long e-mails! Before you wrote in, I had no idea that a re-pricer or reviewer even existed! Which is why I have to double check and make sure I got your valuable postings in the right places within the Overview brain dump before we go over this stuff in the teleconference on Friday. You also have shared with us some definitions of various parties in the past (e.g., 02-26 in RE: Requirements Gathering - Information Flows), but I don't want them in the overview document. Instead, I want to make sure they're elevated to - or used to augment already existing definitions in - the HIPAA Glossary, as Bruce Horn has urged. I'm pretty confident that we can devise any kind of doo-hickeys for describing how routing of interchanges is to be accomplished within a particular CPP, as long as the deviser of the CPP knows ahead of time the criteria for decision-making. For example, the payer knows ahead of time where his portals are, what plans he has, and things like that, so decisions based on these static criteria should be able to be described
Re: Route through email and attach EDI files
Martin: Your e-mail was lost in-between all the stuff about Kennedy's new bill, Gartner's supposed opinion of ebXML, bio-defense and WebMD's stock woes. I now see that your missive actually was very relevant to what we're doing here in the ID Routing group, which is why it was easily overlooked. Imagine that someone is actually thinking about EDI Addresses, rather than big strategic issues! As I mentioned Wednesday, payers at the other end have to support e-mail in exactly the same way; otherwise your PMS can't talk to them, and it won't be worth devising constructs for describing those techniques in the EDI Address. But surely some payers (or intermediary CHs) do (or will) support e-mail, and perhaps you can find out the particulars of the way they implement SMTP portals (and please share the details with this group). Are you familiar with EDIINT (Electronic Data Interchange-Internet Integration)? Not that you may necessarily want to support EDIINT in your software system, but the EDIINT specification will give you some useful background when devising requirements for EDI Addresses pertaining to (regular) e-mail. Take a look at http://www.ietf.org/html.charters/ediint-charter.html, specifically the Internet-Draft for MIME-based Secure Peer-to-Peer Business Data Interchange over the Internet. Perhaps instead of defining stuff in the CPP, assumptions can be made about attachments based on Content-Type and other junk directly in the S/MIME. Additionally, the certificate (public key) itself might give information about encryption algorithms supported by the recipient - in other words, once you've pointed to the certificate in your CPP, you've said all there is to say about how stuff is to be encrypted. William J. Kammerer Novannet, LLC. Columbus, US-OH 43221-3859 +1 (614) 487-0320 - Original Message - From: Martin Scholl [EMAIL PROTECTED] To: William J. Kammerer [EMAIL PROTECTED]; WEDi/SNIP ID Routing [EMAIL PROTECTED] Sent: Monday, 17 June, 2002 08:21 PM Subject: Re: Route through email and attach EDI files William, thanks for your in-depth analysis of the email aspect. I like your description of push versus pull. This stresses one of the main advantages of the email route. I have not really followed the ebXML thread much. All I understand is that its aim is to communicate a set of Trading Partner parameters in a response to a standard XML query. For email we would need something like this email address email address/address maxsize maximal mbytes of attachemnts /maxsize maxnumber maximal number of attachments /maxnumber encryption yesno Yes No Always Sometimes/yesno typePGP or whatever/type publicKey Public Key /publicKey /encryption /email This is my first stab at this, please, anyone amend/delete at your liking and feed it back to the group Martin Scholl Scholl Consulting Group, Inc. 301-924-5537 Tel 301-570-0139 Fax [EMAIL PROTECTED] www.SchollConsulting.com
Re: Route through email and attach EDI files
Deepan: Assuming your Practice Management System processes HIPAA standard transactions, and you intend to transport point-to-point, then I guess you have no choice but to support most conceivable means (protocol and packaging) of sending and receiving interchanges. An alternative is to support just the more common methods (whatever they are in healthcare: we need to determine this), and then encourage your customer to use a VAN or clearinghouse as an intermediary if the payer requires anything weird (e.g., 3780 BSC). Your core-competency is probably not communications software, so it's possible you're limited to the protocols supported in whatever third-party comm package you've perhaps integrated into your system. Just like with the Cleos, IpSwitches and EDIINT packages of the world, your customers will have onerous manual setup for each of their payers. I hate modems and comm settings (and printers), so I am only too relieved to have a single Internet connection to the world - that simplifies things quite a bit. But even with the internet (FTP, SMTP and HTTP) and the payer-centric mailbox model, there's still manual setup for each payer required. Eventually, if every payer (or their CH proxy) supported the CPP, you could write your software so your customer would be able to insert the CPP (Electronic Partner Profile) to auto-configure the communications settings. And then even later on, your software could be made smart enough to search the Healthcare CPP Registry so CPPs wouldn't have to be manually handled. That's the vision thing, anyway. In the meantime, you're on your own. So to help us out in determining requirements for the EDI address (DeliveryChannel) part of the CPP, perhaps you could give us the details of communication methods demanded in your marketspace - in effect, the protocols supported by payers. We need meat and detail. I vaguely know there're some common ones supported by payers (e.g., XMODEM, XMODEM-1K, YMODEM, YMODEM-G, ZMODEM, etc. etc.), all requiring dial-up into the payer's system. Will payers and CHs be supporting SMTP, EDIINT, FTP or HTTP over the Internet? If so, please share the details. These aren't competitive trade secrets. This is also an invitation to payers and clearinghouses to share their supported communication protocols. Again, if you and Julie Thompson really have reason to think the Final Security regulations might completely change the choices available for transaction routing, tell me what you believe - if only your speculation - and your rationale for believing so. I'm not a mind-reader, and would prefer to work with detail rather than vague pronouncements. I doubt seriously that any of the final regulations will specify (or disallow) particular transport methods, or change the requirement that encryption be used when transmitting PHI over the public Internet. Common sense will dictate that encryption excludes home-grown cipher techniques, whether or not explicitly stated in the regs: it would be irresponsible to use any but peer-reviewed encryption algorithms (in effect, standards such as the symmetric IDEA, RC2, RC4, DES, DES3 and Blowfish, and the asymmetric RSA), or PGP and X.509 PKIs. William J. Kammerer Novannet, LLC. Columbus, US-OH 43221-3859 +1 (614) 487-0320 - Original Message - From: Deepan Vashi [EMAIL PROTECTED] To: Martin Scholl [EMAIL PROTECTED]; William J. Kammerer [EMAIL PROTECTED]; WEDi/SNIP ID Routing [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Tuesday, 18 June, 2002 05:05 AM Subject: Re: Route through email and attach EDI files For payers it might be easy to decide on their Internet strategy. I represent a Provider Software Vendor, offering Browser based interface. We have no choice but to design a system that will handle all ftp, smtp, http and any other vendor specific methods to make sure that provider claims (and transactions) reach payers. Moreover, Final Security Regulations might completely changes the choices available for transaction routing. All this talk about transaction routing, appear like a *dark tunnel*. What internet and routing strategy should be adopted by a web based provider software vendor like us? I believe there will be many like us in the industry offering practice management software to doctors; what are they planning for routing treansactions? Any *ray of hope* will be appreciated. Deepan Vashi www.ipmsolution.com Efficient Healthcare Delivery and Practice Management
Re: The payer centric model
Maybe I misunderstood Bruce's earlier note from Thursday. I got the impression he was saying that (some) payers do not use CHs (or VANs) - instead the provider has to come to them specifically to retrieve their EDI documents. In the supply-chain world, it is reputed that a certain mass retailer enjoys such dominant market power that it can force its suppliers to endure the humiliating spectacle of dialing into them using obsolete communication protocols, requiring the purchase of an expensive modem of use only in that one relationship. Supposedly, the supplier is even forbidden to employ his own intermediary (such as a VAN) to serve as his proxy, adding further to the indignity. It's possible I have a mistaken impression that this market imbalance and bullying is widespread in the Healthcare arena: each payer the retailer in question, every provider a humiliated and downtrodden supplier from whom every penny is squeezed in concessions. If 30 payers were forcing a particular provider to do that, obviously the provider has 30 connections to make. In the best of worlds, he only has a few modem varieties that he needs to install. Each one of these connections will be different, and are burdensome with even the best packages, as the provider has onerous communications maintenance (key management, dial-up numbers, protocol settings, IP addresses, FTP directory settings, logon IDs, passwords, ISA settings and so on). If it's tough on the provider, I can imagine it's an even a bigger burden on the payer, though obviously she usually has more IT resources; maintaining thousands of connections manually can't be that much fun! The promise of Internet EDI (EDIINT) software fell short simply because it's often easier and cheaper for both parties to delegate communications headaches to an intermediary, such as a VAN or clearinghouse. Then you don't have to worry about either temporal or protocol incompatibilities, and you've avoided the heartbreak of onerous connection setups. And EDIINT software is often easier to use (because of fewer protocols and consistent key management) than the various general purpose FTP packages out there. But the manual communication configurations are the least of the EDI hookup problems, as we've oft-discussed. Onerous paper-based TPAs and EDI enrollments add further friction to the process. It's only natural that providers (or their CH agents) use a variant of the 80-20 rule: it's such a hassle to do EDI, that we'll only do it (if at all) with the few payers who handle 80% of our claims. The long term benefits of this project not only include automated partner setup, but facilities to eliminate paper TPA and EDI enrollment requirements. William J. Kammerer Novannet, LLC. Columbus, US-OH 43221-3859 +1 (614) 487-0320 - Original Message - From: Bruce T LeGrand [EMAIL PROTECTED] To: WEDi/SNIP ID Routing [EMAIL PROTECTED] Sent: Friday, 14 June, 2002 09:35 AM Subject: RE:The payer centric model William, I am always amazed that providers have to do that. I have intimate experience in this market and with several different practice management systems, vendors and support units. None of these will make the provider do anything even remotely looking like the scenario you use a byplay in your examples. Wait and see how the problem is approached by some very motivated, creative system vendors before we go declaring that HIPAA has done nothing to ease the burden on the provider. I think you will find that is not the true circumstance. And if a vendor is not doing what is necessary, I'd expect that their life in the changing market will be short lived. --( Forwarded letter 1 follows ) Date: Thu, 13 Jun 2002 13:29:14 -0400 To: WEDi/SNIP.ID..Routing[routing]@wedi.org.comp From: William.J.Kammerer[wkammerer]@novannet.com.comp Sender: [EMAIL PROTECTED] Subject: The payer centric model Payers are required to use standard transactions if the provider requests that they do so. Somehow the messages have to be gotten to the provider. In the typical supply-chain scenario using VANs and interconnects, the sender merely pushes the interchange to his VAN. Then the sender's VAN itself will worry about delivering it to the receiver's mailbox (if coincidentally subscribed to the same VAN), to another VAN to which the receiver is subscribed, or even directly to the receiver (using a push model) if the receiver has arranged that service with his VAN. It's not the sender's (the payer in our case) problem to arrange mailboxing for the receiver. Quite a bit of time, trouble and money can be saved if each payer didn't think it had to play VAN. And it certainly shouldn't be the problem of the receiver (the provider in our case) to go traipsing off to 20 or 30 payer websites to retrieve standard transactions, going through each payer's notion of a logon process and mailbox retrieval. It makes sense to learn that process for your one and only VAN
Re: The payer centric model: And round and round the mulberry bush we go!
When the WEDI/SNIP Business Issues management team created the ID Routing SIG, I can't help but feel that they certainly understood where this project would head. The Business Case for the development of EDI Address Specifications was succinctly stated in EDI Address: Business Case Requirements (Draft Document 6320), available at http://www.novannet.com/wedi/. See section 1.0, Business Case for Development of EDI Address Specifications: Health care information operates in a many-to-many communications environment, involving tens of thousands of payers and hundreds of thousands of health care providers, as well as clearinghouses, network operators, and other participants, where every doctor, hospital, payer, and other participant potentially communicates with any other participant. EDI based solely on interlocking bilateral arrangements is too limiting. The requirement is for an addressing structure that is standard. EDI Addresses are essential for equal participation. They are a part of giving every participant, especially providers, the ability to receive transactions without having to poll multiple possible senders. The CPP Electronic Partner Profile grew out of the desire to have not only a machine-readable representation of EDI Addresses, as the project document originally envisioned, but also any other kind of common characteristics shared between partners (e.g., certificates, companion guides, certification credentials, supported transactions, etc.). Enabling the payer-centric mailbox model to go away is clearly the goal BI management had in mind for this project. It's obviously what the co-chairs of this group signed up for. And we're on our way to doing just that, undaunted by schoolyard taunts. William J. Kammerer Novannet, LLC. Columbus, US-OH 43221-3859 +1 (614) 487-0320 - Original Message - From: Rachel Foerster [EMAIL PROTECTED] To: 'WEDi/SNIP ID Routing' [EMAIL PROTECTED] Sent: Friday, 14 June, 2002 06:23 PM Subject: RE: The payer centric model And round and round the mulberry bush we go! Making the payer-centric mailbox model go away or even enabling it to go away is not the objective of this group. Rachel Rachel Foerster Rachel Foerster Associates, Ltd. Phone: 847-872-8070 -Original Message- From: William J. Kammerer [mailto:[EMAIL PROTECTED]] Sent: Thursday, June 13, 2002 12:29 PM To: WEDi/SNIP ID Routing Subject: The payer centric model Payers are required to use standard transactions if the provider requests that they do so. Somehow the messages have to be gotten to the provider. In the typical supply-chain scenario using VANs and interconnects, the sender merely pushes the interchange to his VAN. Then the sender's VAN itself will worry about delivering it to the receiver's mailbox (if coincidentally subscribed to the same VAN), to another VAN to which the receiver is subscribed, or even directly to the receiver (using a push model) if the receiver has arranged that service with his VAN. It's not the sender's (the payer in our case) problem to arrange mailboxing for the receiver. Quite a bit of time, trouble and money can be saved if each payer didn't think it had to play VAN. And it certainly shouldn't be the problem of the receiver (the provider in our case) to go traipsing off to 20 or 30 payer websites to retrieve standard transactions, going through each payer's notion of a logon process and mailbox retrieval. It makes sense to learn that process for your one and only VAN or clearinghouse - but it hardly contributes anything to administrative simplification for the provider to have to repeat that process for every payer with whom he expects to exchange standard transactions. In a lot of ways, the payer-centric way of doing e-business reminds me of the DDE conundrum, whereby each payer persists in expecting every provider to learn the intricacies of his own eligibility web page rather than merely supporting the 270/271 standard transactions in a first-class manner as required by the TCS rule. William J. Kammerer Novannet, LLC. Columbus, US-OH 43221-3859 +1 (614) 487-0320
Re: An Overview or Primer Document
Rachel: I hadn't really thought of that before: using the critical timelines to sell the concept of the Healthcare CPP and Registry. But now that you bring it up, the overview should definitely include verbiage on how the CPP especially facilitates the industry achieving these critical milestones. Would you mind doing that part of the overview? Obviously, most folks are going to continue using Clearinghouses to help them become HIPAA compliant, but as we've long said, the CPP and Registry are useful to intermediaries also. With Internet connections to clearinghouses and CMS, there are the new HIPAA mandated security rules to deal with which require signatures and encryption - and the CPP is the ideal mechanism for sharing and disseminating certificates. And though it's a given that payers have to support all the standard transactions, the CPP is critical for broadcasting the capabilities of individual providers, avoiding onerous manual interaction as standard transactions are brought online one at a time. Though I'm no big fan of *mandatory* certification, certification is still a good thing to have: the CPP is the most efficient means of conveying your certified capabilities to your partners. And though it could be left unsaid - after all the discussion of the last couple of weeks - I'll say it again: I think Open-EDI is going to spring on many payers as a surprise by H-day, and only an automated infrastructure provided by the CPP and the Registry will make that at all possible. Thanks again, William J. Kammerer Novannet, LLC. Columbus, US-OH 43221-3859 +1 (614) 487-0320 - Original Message - From: Rachel Foerster [EMAIL PROTECTED] To: 'WEDi/SNIP ID Routing' [EMAIL PROTECTED] Sent: Tuesday, 11 June, 2002 06:45 PM Subject: RE: An Overview or Primer Document No, William. I'm not at all suggesting that the CPP or any ebXML registry needs to address any filing submission under ASCA. That would be something that should be determined as part of a requirements analysis and management effort. I was identifying critical timelines by which the health care industry must comply with various aspects of HIPAA and trying to determine how any of these proposed working papers either facilitate the industry achieving these critical milestones and/or remove barriers and obstacles to the industry achieving these milestones. Rachel
Re: digital certificates for access to CPP repository
In the current version of the OASIS ebXML Registry specification, there are no provisions for confidentiality of Registry content. All content submitted to the Registry may be discovered and read by any client - which means anybody can find out that an entity is accessible via the registry, and where their CPP is located. On the other hand, only authorized submitters who have been authenticated using digital signatures can publish data in the registry. I am assuming that this means there exists a fine-grained mechanism whereby only the owner (or his agent) of information (e.g., the CPP) can submit or change his own information - as opposed to having to submit his information through a central authority for inclusion in the Registry. The CPP owner may have some means of obfuscating his own CPP, or parts thereof - revealing information only to authorized users- since the CPP itself could very well reside on his own server. Of course, I'm making a lot of assumptions. The details have to be ferreted out by the folks responsible for the working paper on Discovery of Healthcare CPPs: Peter Barry, Joe McVerry, and Dick Brooks! I think Joe only volunteered to look into UDDI. That leaves Peter and Dick to be the experts on the ebXML Registry. Maybe I could add Lisa Carnahan to the list, too. Does anyone else want to volunteer? William J. Kammerer Novannet, LLC. Columbus, US-OH 43221-3859 +1 (614) 487-0320 - Original Message - From: Christopher J. Feahr, OD [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, 10 June, 2002 06:31 PM Subject: digital certificates for access to CPP repository Dear Group: I would like to know if we have agreement (or could agree) on the following requirements regarding access to the CPP registry/repository data: 1. Allow any party to access the CPP registry, thus obtaining the URL that points to an entity's repository record(s). 2. Require a standard mechanism for entrance to the CPP repository record that somehow looks for a valid digital ID certificate If every CPP repository user was required to have a valid ID certificate somewhere (e.g., the AMA/Verisign deal that was mentioned once) then requiring that certificate as the entry pass to the repository would seem to be a way to keep the riff-raff out. I think we may still need ways to individually [further] secure sections of the repository record, but would a dig. certificate be a reasonable way to secure the repository front door? My suggestion would be to include a data element in the repository (perhaps another URL) that pointed to a default access denied message created by the repository record owner. (I guess in the absence of an entity-specific access denied message that provided an alt. means like a cust. service phone #, the user would simply get a page not found error) More questions (assuming that we do want to secure the front door with a certificate): 1. How tough are these to obtain? Could Mr. Hacker apply for one and thereby have the keys to the kingdom? 2. Are there standard protocols (possibly in the ebXML CPP specifications) for implementing this type of auto-authentication when you attempt to access a URL? 3. How many data elements would be necessary in the repository record to handle auto-auth... and what would they be called? Regards, Chris Christopher J. Feahr, OD http://visiondatastandard.org [EMAIL PROTECTED] Cell/Pager: 707-529-2268
There is today - and the desired future
National Identifiers, such as the NPI, the Plan ID and the Employer ID don't really have any direct bearing on our work. Having a unique domain of IDs to work with to identify providers (and their roles), payers and sponsors is obviously a boon to healthcare applications and operations. But as we have long discussed, a uniform means of identifying healthcare EDI participants is not mandatory for the success of our proposed Registry and CPP electronic partner profile. As long as *some* unique ID is available for searching (e.g., NAIC co-code, DUNS, Tax ID, etc.) the Registry, CPP electronic partner profiles can be located. The CPP itself would indicate the ID qualifier and value to be used in the ISA for interchanges sent to the receiver, along with the technical EDI address (e.g., protocol, network address, etc.). In short, the existence or non-existence of the National Identifiers is irrelevant to our specifications; if any do become available, they merely serve as one more viable identifier domain. Our work is not dependent on any of the National Identifiers. Having said that, it would be advantageous to have the National Plan ID as part of the insurance member card; as shown in my slides illustrating the Healthcare CPP Registry, at http://www.novannet.com/wedi/WEDI%20Healthcare%20Registry.ppt, it would be a fairly simple process to go from the card to the plan and then to the CPP of a TPA or Insurance company. Barring the existence of the National Plan ID, other identifiers for the payer would have to be used as locators (having been found some way, if not printed on the card itself). Payer to payer EDI, as with the 269 COB payment verification transaction set, is not expected to pose any unique problems: either payer would have a CPP which could be located in the Registry, and used just as in the provider-payer (or provider-TPA, or Employer-Plan, or CH-CH) model. The CPP is independent of the role an entity plays: it merely identifies the transactions he supports, and the EDI addresses to which transactions can be sent. Further, the CPP can be used independently of any Registry. The CPP is merely a machine readable XML document which describes or locates an entity's technical trading partner information, such as its EDI addresses, X.509 certificates, supported transactions, ISA and GS requirements, and companion guide information, among other things. These are matters that any entity has to discuss with any of its partners, and having a consistent machine-readable format to hold this information will be an advantage in ramping up trading partner recruitment and configuring EDI translation software. At a minimum, the CPP can be rendered in a neat human readable manner on any browser, long before any automated software can handle it. Implementation of the CPP electronic partner profile is just the first step to complete Open-EDI and frictionless e-commerce in the Healthcare e-marketplace. Even by itself, it is incredibly useful, introducing standardization in trading partner setup and EDI enrollment. There is no reason to think we couldn't have a workable schema for CPP electronic partner profiles before the end of the year, depending on how hard we work. The Registry itself is a convenience: it is not critical to the CPP electronic partner profile. But once we have a registry, we'll wonder how we ever did without it! The Registry will allow you to share your CPP electronic partner profiles, without your partners' having to track you down manually. Though the registry involves a few more variables than building the CPP, we could have a workable prototype in short order with the assistance of NIST. Its use would be voluntary, but would there be any good reasons not to use it to point to your own CPP if it were available? It would save you the hassle of answering individual calls asking how to send transactions to you. Or where is your X.509 certificate for encryption? Or what do you expect in the ISA? And questions of that ilk. Though the CPP and the Registry specifications are a little more ambitious than the original modest goal (devising EDI Addresses to establishing connectivity) we set out for ourselves last February, I don't think there's much here that is Buck Rogers pulp fiction. Don't get hung up on the Open-EDI business quite yet. The CPP and Registry will be incredibly useful whether or not Open-EDI comes to pass. But nevertheless, I happen to believe that HIPAA in effect mandates Open-EDI, and only an automated infrastructure including the CPP and the Registry will make it possible for payers to conform to the spirit of the law. William J. Kammerer Novannet, LLC. Columbus, US-OH 43221-3859 +1 (614) 487-0320 - Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Friday, 31 May, 2002 09:22 AM Subject: RE: TA1 responding to non-participating health care providers In my opinion
An Overview or Primer Document
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) A little more background on the project and working papers is available at http://www.novannet.com/wedi/. Lynne Gilbertson's message reminds us that a primer (or Overview or Background) document is really necessary - something that says in plain English (or bloated, turgid English if I were to write it) just why we're going to all this trouble to build an electronic partner profile - and a Registry to point to it! 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. I propose that the first Working paper, Identifiers, simply be changed to an Overview document. Currently, Ron Bowron and I are assigned to the Identifiers document; if there's no objection to turning the working paper into a usable overview of the project, would there be anyone else who would like to volunteer to assist us in writing it? I anticipate that a large part of the document will be an organized and edited cut-and-paste of postings to the ID Routing mailing list over the last 4 months. William J. Kammerer Novannet, LLC. Columbus, US-OH 43221-3859 +1 (614) 487-0320 - Original Message - From: Lynne Gilbertson [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, 06 June, 2002 04:35 PM Subject: RE: registry and repository NCPDP has created a task group to assist in the routing registry endeavor. As the task group is made up of business and technical folks in the pharmacy industry, is there a primer document or something they can read to come up to speed with the work being done? thank you
NCPDP
Lynne: HIPAA mandates the NCPDP Retail Pharmacy electronic transactions between pharmacists and payers for eligibility, claims and remittance advices. We had previously discussed including NCPDP transactions in our plans, but had been dissuaded from doing so; see http://www.mail-archive.com/routing@wedi.org/msg00556.html. I'll echo Chris Feahr: Perhaps you could provide the group an overall description of the envelope structure and message transport mechanisms used in the NCPDP system. 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. William J. Kammerer Novannet, LLC. Columbus, US-OH 43221-3859 +1 (614) 487-0320 - Original Message - From: Lynne Gilbertson [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, 06 June, 2002 04:35 PM Subject: RE: registry and repository NCPDP has created a task group to assist in the routing registry endeavor. As the task group is made up of business and technical folks in the pharmacy industry, is there a primer document or something they can read to come up to speed with the work being done? thank you
Re: registry and repository- version control
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. William J. Kammerer Novannet, LLC. Columbus, US-OH 43221-3859 +1 (614) 487-0320 - Original Message - From: Dave Minch [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, 05 June, 2002 10:45 PM Subject: RE: registry and repository- version control The CPP spec does allow for versioning. I've used the trading partner profile from our Sybase paperfree application as a model for TP information, and have added several elements beyond that. Rachel is correct in that most EDI translators appear to have a more or less sophisticated trading partner profile management function. Dave Minch TCS Project Manager John Muir / Mt. Diablo Health System Walnut Creek, CA (925) 941-2240
Re: 837/835 routing through clearinghouses
Todd: 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/routing@wedi.org/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). William J. Kammerer Novannet, LLC. Columbus, US-OH 43221-3859 +1 (614) 487-0320 - Original Message - From: Velnosky Todd L [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, 30 May, 2002 05:17 PM Subject: 837/835 routing through clearinghouses I have a question that is articulated in the below hypothetical: 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)? Questions or comments contained herein are not the opinion or position of John Deere Health Care, Inc. or John Deere Health Plan, Inc.
Re: Open Portals and Blind Trust
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. William J. Kammerer Novannet, LLC. Columbus, US-OH 43221-3859 +1 (614) 487-0320 - Original Message - From: Dr. Mrs. Mariam Abacha [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, 30 May, 2002 08:26 PM Subject: HELLO Alternate e-mail: [EMAIL PROTECTED] I am Dr. Mrs. Mariam Abacha, wife to the late Nigerian Head of state, General Sani Abacha who died on the 8th of June 1998 while still on active service for our Country. I am contacting you with the hope that you will be of great assistance to me, I currently have within my reach the sum of $18.92 million U.S dollars cash which l intend to use for investment purposes outside Nigeria. This money came as a result of a pay back contract deal between my husband and a Russian firm in our country s multi-billion dollar Ajaokuta steel plant. The Russian partners returned my husband s share being the above sum after his death. Presently, the new civilian Government has intensified their probe into my husband s financial resources, which has led to the freezing of all our accounts, local and foreign, the revoking of all our business licenses and the arrest of my First son. In view of this I acted very fast to withdraw this money from one of our finance houses before it was closed down. I have deposited the money in a security company with the help of very loyal officials of my late husband. No record is known about this fund by the government because there is no documentation showing that we received such funds. Due to the current situation in the country and government attitude to my family, I cannot make use of this money within, thus I seek your help in transferring this funds out of the sub African
Re: 837/835 routing through clearinghouses
Yes, certainly, the provider CAN say that they want the 835 to be delivered to their bank, or a different clearinghouse. But what would the payer do if the clearinghouse or bank came back and said: Whoa, hold on big fella! Before just anyone sends 835s into us, we gotta make sure you're not riff-raff. This could be a trick to infest us with cooties. You gotta show us you're 'certified' with Billy Joe's 835 certification service. And then you gotta sign these forms in triplicate, with signatures affixed by each of your principals and board members. And don't forget to send your incorporation papers. And maybe we'll let you know in 6 to 8 weeks whether we'll let you into our system. And we'll give you a logon ID and password which you can use to get into us between the hours of 5 and 6 a.m. What's good for the goose is good for the gander. In any event, the payer would probably prefer to send the 835 combined payment and ERA through his own bank - and let his bank worry about getting it to the provider's bank. William J. Kammerer Novannet, LLC. Columbus, US-OH 43221-3859 +1 (614) 487-0320 - Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Friday, 31 May, 2002 09:29 AM Subject: Re: 837/835 routing through clearinghouses I hate to say this, but the 835 will be a totally different beast. The provider CAN say that they want the 835 to be delivered to their bank, or a different clearinghouse. The 835 route can be different than the claim route - in fact, there does not have to BE a claim route - paper claims go on the 835 as well as electronic claims. Also, the 835 represents a check or EFT. Any single 835 may have claims that came to the payer from the provider by two different routes or entry points. Bob
Re: TA1 responding to non-participating health care providers
Out on EDI-L, while discussing the open-EDI aspect of Healthcare - you know: claims coming in from unknown or non-par providers - folks are sharing their ailments as part of their stories. I won't do that here, as I save those stories for my neighbors on the plane. But suffice it to say, a recent provider of mine was the OSU Dental Faculty Practice (part of The Ohio State University College of Dentistry). The nice lady there with whom I discussed the bill said Anthem (the local BC/BS to which I subscribe) doesn't talk to OSU Dental Faculty Practice. I guess that's another way of saying they're unknown, though I thought everyone knew who OSU was. Anyway, OSU can send the claim to Anthem (paper, electronic, or through a billing service - I have no idea), but Anthem will not respond to them at all. Instead, she warned me, Anthem will send me a (paper) EOB and possibly a check. A couple of points are manifest in this story: (1) for my own administrative simplification, OSU graciously agreed to submit a claim on my behalf; (2) at least Anthem deigned to take a claim - I can picture them holding their nose all the while - from the unknown OSU on my behalf; and (3) the check, if any, would be paid to me, the subscriber. This makes perfect sense, and conforms to my notion how claims and payments are handled for out-of-network (or is OSU unknown?) providers: payments should only be made to folks with whom the payer has a contract - in this case, me, since OSU is, well, unknown. HIPAA does not require that Anthem pay the unknown OSU. It would have been nice if Anthem were to send an EOB to OSU, also - but not critical. Since Anthem is not paying OSU, there's no need for 1099s - solving Bruce's problem of reporting unknown provider income to the IRS. 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). William J. Kammerer Novannet, LLC. Columbus, US-OH 43221-3859 +1 (614) 487-0320 - Original Message - From: Bruce T LeGrand [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Thursday, 30 May, 2002 08:52 AM Subject: RE: TA1 responding to non-participating health care providers Hello Rachel, 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. --( Forwarded letter 1 follows ) Date: Wed, 29 May 2002 16:43:36 -0500 To: [EMAIL PROTECTED] From: Rachel.Foerster[rachelf]@ix.netcom.com.comp Sender: [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] Subject: RE: TA1 responding to non-participating health care providers Martin, My apologies for mis-using the term non-par (non-participating) when I truly did mean unknown.I think some of the scenarios posted today describe this potential circumstance. 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? Rachel
Re: Trading Partner ID
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! William J. Kammerer Novannet, LLC. Columbus, US-OH 43221-3859 +1 (614) 487-0320 - Original Message - From: Michael Mattias/Tal Systems [EMAIL PROTECTED] To: WEDi/SNIP ID Routing [EMAIL PROTECTED] Sent: Thursday, 30 May, 2002 07:59 AM Subject: Re: Trading Partner ID - Original Message - From: Martin Scholl [EMAIL PROTECTED] Subject: RE: Trading Partner ID Thanks for all the input. That helped a lot with the ISA/GS issue. But how about the loop 1000 , NM1_08 and NM1_09 with the 40/41 qualifier. What are you guys doing there usually? Again use the same IDs as in ISA 06 and 08? As has been pointed out by others, the ISA, GS and between the ST-SE identifiers are COMMONLY set to the same values. Of course, it is also COMMON for people to go out in the rain without an umbrella; but that doesn't make it smart. One of the problems setting the ISA, GS and N1/ NM1/PRV segment identifiers to the same value solves is the problem of poorly-designed EDI software. (This does not apply just to homegrown systems, it includes several commercial offerings). Poorly-designed software comes from designers who do not understand the purposes for which the various ANSI ASC X12 envelopes were designed: ISA/IEA Envelope: Gets the interchange to the correct destination (application partner, agent or backup processing site); often (well, nearly always) used by VANs to route to the correct destination mailbox, with a check that the VAN receiver has in fact authorized the receipt of interchanges from a certain sender (this is a bad check: it should be done after the file is delivered, but this is not a universally held view). GS/GE Envelope: Routes the functional group to the correct party or department within the destination; e.g, Purchase orders (group PO) and PO changes (group PC) go to the sales department; Invoices (group IN) go to accounting, etc, etc. ST/SE envelope: Delimits documents containing the specific identities for this business transaction; e.g, My customer/vendor/provider number is . You mentioned, If I receive a transaction, I key the trading partner to the ISA_06 element. This is, IMNSHO, an inferior choice. It's like tracking mailed documents based on the post-office of the sender. You don't do this in real life: you track documents based on the identifiers found within the document, don't you? You asked, For me the issue is: What do I use as a unique key to store trading partner rules and information under? What do others in the field do? What others in the field do is immaterial, as many of them are limited by their software (and their wetware). Given your druthers (and yes, I understand we don't all get our druthers), use the identifiers within the transaction set. So you have answered this yourself: .. in the 837 I also have this pesky 1000A loop with another set of Sender IDs. As the identifiers within the transaction set, these should be your ID's of choice. This does NOT mean you cannot use something else to accomodate your mapping software. For example, you may need to map the transaction set somewhere just to figure out if you wish to further process this document from the sending party as identified within the transaction set. However, you should be able to do this kind of mapping without regard to the applications identifiers based solely on the version/release in the GS segment. In an ideal world (give me a break, I grew up in the 1960's and I am an idealist), using this document approach will be the long-term winner. Michael Mattias Tal Systems, Inc. Racine WI [EMAIL PROTECTED] www.talsystems.com
RE: TA1 responding to non-participating health care providers
We're not really worried about how folks do eligibilities in the short term (pre-HIPAA). 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. William J. Kammerer Novannet, LLC. Columbus, US-OH 43221-3859 +1 (614) 487-0320 - Original Message - From: David Frenkel [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, 30 May, 2002 12:32 PM Subject: RE: TA1 responding to non-participating health care providers Mimi, As alluded to by Bruce, the Blues have this process in place which includes an 800 number for eligibility. State Medicaids are talking about accepting out of state Medicaid claims; I think the details are still in the works. For out of network claims for the short term you may have to stick to paper. Regards, David Frenkel Business Development GEFEG USA Global Leader in Ecommerce Tools www.gefeg.com 425-260-5030 - Original Message - From: Bruce T LeGrand [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Thursday, 30 May, 2002 11:42 AM Subject: RE: TA1 responding to non-participating health care providers Mimi, in the case of the blues, you would send your eligibility request to the Iowa version of the blue plan, whomever that may be. That's part of the national agreement the blues have through their interplan transaction service. --( Forwarded letter 1 follows ) Date: Thu, 30 May 2002 09:26:49 -0500 To: BRUCE.LEGRAND, [EMAIL PROTECTED] From: Mimi.Hart[HartAM]@crstlukes.com.comp Subject: RE: TA1 responding to non-participating health care providers Requesting clarification on this point.. 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.) Mimi Hart Research Analyst, HIPAA Iowa Health System 319-369-7767 (phone) 319-369-8365 (fax) 319-490-0637 (pager) [EMAIL PROTECTED]
The Healthcare CPP Registry presentation
The slides for The Healthcare CPP Registry, presented at the WEDI 2002 National Conference in Denver last Wednesday, are available at http://www.novannet.com/wedi/WEDI%20Healthcare%20Registry.ppt. It just has a high level overview of identifiers and their use in discovering CPP electronic partner profiles via some kind of Oracle - our Healthcare registry. This is my second Powerpoint of my career, so cut me some slack on the graphic I used for an oracle - a magician's hat! William J. Kammerer Novannet, LLC. Columbus, US-OH 43221-3859 +1 (614) 487-0320
Re: CPP Data elements draft for comment
Michael: Thanks for your input. Any good technical junk regarding Healthcare Partner profiles (CPP) and Registries is welcome for discussion on the list. I have heard comments from some folks that there's just too much e-mail on this list, but I figure there can't be enough discussion of technical issues. And besides, it would be far better to somehow eliminate off-topic discussions - like the AHA vs. DHHS issue of late - if we really need to have some liposuction done on the ID Routing mailing list. That's not to say it's not an important issue, but it should be moved to the Business Issues mailing list, with no cross-posting. I encourage folks to please review Zon Owen's e-mail on SNIP Listserv Usage Etiquette Guidelines that he posted to the Business Issues Listserve at http://www.mail-archive.com/business%40wedi.org/msg00311.html on April Fool's Day. Quite reasonably, Zon suggests that [postings] to subordinate listservs [like the WEDi/SNIP ID Routing mailing list] should be relevant to the specific activities and work products of those subgroups. Your suggestions - technically reasonable or not - seem to be right on target for developing the Elements of the Healthcare Collaboration-Protocol Profile (CPP). If you were to send your suggestions just to Chris, it would put too much of an administrative burden on him to consolidate and share with the others on his team. There's supposed to nothing secret in an open standards development effort (except administrivia like meeting arrangements and coup d'état planning), and this is just the right stuff to engender thought-provoking discussions, fur-ruffling and polite arguments. As a technical aside, I might 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. William J. Kammerer Novannet, LLC. +1 (614) 487-0320 - Original Message - From: Michael Mattias/Tal Systems [EMAIL PROTECTED] To: WEDI/SNIP Listserve [EMAIL PROTECTED] Sent: Sunday, 05 May, 2002 10:17 AM Subject: Re: CPP Data elements draft for comment - Original Message - From: Christopher J. Feahr, OD [EMAIL PROTECTED] Here's the link to my proposed CPP template/spreadsheet. (thanks, William): http://www.novannet.com/wedi/CPP_Elements.xls You may want to hold off on commenting until you have seen a similar CPP template proposal that Dick Brooks has been working on. Very, very nice...I like it. I look forward to Mr. Brooks' version, too. Just one question: Looking through this I noticed the absence (can you notice an absence?) of some data fields needed for an applications developer (e.g., me). What I am looking to do when I query the registry is to end up with all the data I would need to create a document (837, 270, 276, etc), send an ANSI interchange and have it get to the receiver, then have it pass the receiver's (non-medical) edits; that is, including such things as the ap plications identifiers. For example, some data fields which occur to me right off the top of my head...(270=Eligibility Inquiry) AcceptsRealTime270 - does this Information Source (payer) accept realtime 270's? AccceptsBatch270- does this Information Source accept batch 270's? ApplicationID270RealTime - GS ID for payer for 'realtime' 270 ApplicationID270Batch - GS ID for payer's 'batch' 270 BatchLimit270 - maximum number of requests per single 270 in batch mode RealTimeTimeout - if no response to a 270 in 'n' seconds/minutes, give up. BatchTurnaroundTime - if no response to a 270 in 'n' hours/days, consider 'overdue' (Your 'NormalResponseTime and SessionTimeout fields may cover the Timeout/Turnarounds, but I would like to see it expanded to allow for different times for different documents) Right now I am focused on the 270/271 (like you hadn't figured that out) and can provide a bunch of data fields for inclusion. (A DOCUMENT section in addition to CONNECTION would be just fine). To whom shall we send these suggested additions, or do we just post 'em here and hope for the best? ( Moderator help?) (Note: I sent this to a communications expert with whom I may work and he may comment as well). Michael Mattias Tal Systems, Inc. Racine WI [EMAIL PROTECTED]
Re: our section of the paper wrt. ProcessSpecification/Role/ServiceBinding/Service
Dick: 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/routing@wedi.org/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. William J. Kammerer Novannet, LLC. +1 (614) 487-0320 - Original Message - From: Dick Brooks [EMAIL PROTECTED] To: Christopher J. Feahr, OD [EMAIL PROTECTED]; Dick Brooks [EMAIL PROTECTED]; Marcallee Jackson [EMAIL PROTECTED]; Dick Brooks [EMAIL PROTECTED]; Dave Minch [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Sunday, 05 May, 2002 11:32 AM Subject: RE: our section of the paper Chris, et al., I just wondered whether we wanted to describe or try to diagram/model the related business processes in the white paper. I think a model of the various business processes is a great idea. This would certainly help flush out the CPP elements if we intend to define CPP elements for each of the various business processes. I suspect this may be a larger task than a simple file exchange business process definition. Thinking about the process model (like the one Dave Minch created) is certainly helpful in coming up with the required list of CPP data elements, but it may not be necessary to describe all that in the paper... at least not in great detail. Ditto. I believe the CPP that this group delivers will be based on your list of CPP data elements (nice job), plus details of the specific business process used. At this point I believe we need to choose a direction regarding the business process. Should we define ProcessSpecification/Role/ServiceBinding/Service elements for each HIPAA business process (e.g. a claim service request, results in a remittance advice or an 824 application response etc.) OR define a simple file exchange process (Upload/Download) OR Both? This decision will help guide us down the correct path. Dick Brooks Systrends, Inc 7855 South River Parkway, Suite 111 Tempe, Arizona 85284 Web: www.systrends.com http://www.systrends.com Phone:480.756.6777,Mobile:205-790-1542,eFax:240-352-0714
Re: Minneapolis X12 Meeting and Appointment of Working Paper Editor
I made a boo-boo. My enthusiasm for our ID Routing project got a little ahead of me on Friday, when I announced a forum for discussions at the June X12 meeting in Minneapolis. As way of background, Peter Barry and I have been looking for possible ANSI ASC X12 subcommittee sponsors of a Face-to-Face meeting on the Healthcare CPP Registry. Unfortunately, I misread the first we'll look into it response as an invitation to the party. In any event, arranging and planning a session will take a bit more discussion, and I will let you know the particulars once they have been settled one way or another. I have confidence that one or more X12 subcommittees will be able to accommodate a Healthcare CPP Registry forum. X12 - along with its individual members - has been a committed partner and supporter of the UN/CEFACT and OASIS ebXML process. It's probably reasonable to assume that X12 will be favorably disposed towards our efforts to apply the ebXML CPP and Registry as solutions to some of the problems arising in the rollout of standard X12 transactions within Healthcare. William J. Kammerer Novannet, LLC. +1 (614) 487-0320
Medicare says 'no' to using the open internet
I came across Christine Stahlecker's presentation entitled Telecommunication and HIPAA: Issues, Concerns, Recommendations, given at the HIPAA SUMMIT WEST II on March 13 in San Francisco, at http://www.ehcca.com/presentations/HIPAAWest2/stahlecker.ppt. In there, she gives some buzz to our modest little work effort. Clearly, Chris shares our vision of Open-EDI and frictionless trading using the Internet, while still accommodating the important role of Clearinghouses in supporting providers and payers. Unfortunately, from what I can gather from one of Chris' bullets, a fly in the ointment is Medicare's (CMS) refusal to entertain use of the Internet for the exchange of standard EDI transactions because of real or perceived security concerns. Unless and until CMS changes its mind and authorizes the use of the Internet to exchange HIPAA transactions with Medicare contractors, we might have to provide some capability in our Delivery Channel (EDI Address) to accommodate dial-up or leased line protocols - regardless of what I said in Should we even waste time defining Delivery Channels (EDI Addresses) to accommodate non-IP protocols? last Tuesday. Does anyone have any inside insight on CMS' resistance to using the Internet for the exchange of standard transactions? William J. Kammerer Novannet, LLC. +1 (614) 487-0320
Re: Data Elements for the WEDI-SNIP-CPP
The OASIS ebXML Collaboration Protocol Profile and Agreement TC Web page is at https://www.oasis-open.org/committees/ebxml-cppa/, where the current draft (ebCPP-1_11.pdf) of the spec can be obtained. An even newer CPPA Version 1.12 can be found in the e-mail archives at http://lists.oasis-open.org/archives/ebxml-cppa/200204/msg00055.html. As Rachel said, the CPP/CPA is **NOT** about a registry at all. There is a separate ebXML specification for the registry/repository portion of the ebXML architecture. The examination of the ebXML Registry really comes under the Discovery working paper group's aegis: Peter Barry, Joe McVerry, Dick Brooks will be studying UDDI, the ebXML Registry and Kepa's DNS directory recommendation. Your working paper group, Elements of the CPP, will be concentrating mostly on what's needed in the ebXML CPP to support healthcare, and should be able to be designed independently of whatever registry (or registries) the other group recommends. 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. Distributing PDF or Word documents seems perfectly okay to me, though I know there are Linux pin-heads (no offense intended, Kepa) out there who get all upset at the idea of using anything M$ related!! William J. Kammerer Novannet, LLC. +1 (614) 487-0320 - Original Message - From: Christopher J. Feahr, OD [EMAIL PROTECTED] To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Saturday, 20 April, 2002 06:43 PM Subject: RE: Data Elements for the WEDI-SNIP-CPP Rachel, Thanks for clarifying the relationship between the CPP specification and the separate CPP registry-structure specification. If I understand the immediate task assigned to me, Dave, and Marcallee, however, it is to propose a list of data elements that we consider important in the WEDI-SNIP CPP. I'm not sure I understand how am I getting off into left field with this? I'm sure it's buried in the email archive, but can you point me again to the draft CPP/A specification? I think what we are after here is just a list of data elements, but I would welcome any further light you can shed on the task I volunteered to help with a few weeks ago. William: Given the unwieldy nature of this email-narrative type knowledge we've accumulated over the last few months, what format would you suggest for group collaboration on some draft documents? I'm just now installing Adobe Acrobat 5.0 and I believe that it allows many people to mark up .pdf documents posted on a web site, using signed notes, etc. Is something like this feasible? The free .pdf reader would allow the whole group to read the document and the notes, but I think you'd have to have the full version of Acrobat to actually mark up the draft copy. I see a need to move this effort to a more organized level, starting with drafts of: 1. Mission and requirements list 2. Definitions of terms used in addressing and routing 3. Proposed data elements for the CPP record Thanks, -Chris At 04:42 PM 4/20/02 -0500, Rachel Foerster wrote: Chris, it's very important that you get the most current specs (draft) on the CPP/A specification to see what it specifies. I fear (no pun intended!) that you may be moving way off into left field where you may not want to beperhaps yet. Let's get the core of the CPP done first. Rachel Foerster Christopher J. Feahr, OD http://visiondatastandard.org [EMAIL PROTECTED] Cell/Pager: 707-529-2268
Fourth National HIPAA Summit: session on Identifiers, EDI Addressing and Routing
Peter Barry and I will be presenting a session on Identifiers, EDI Addressing and Routing at the Fourth National HIPAA Summit at the Renaissance Marriott in Washington, DC. on Friday, April 26, 2002 at 8:00 a.m. See http://www.hipaasummit.com/ for more information about the HIPAA Summit. Peter will cover the National Plan and Provider IDs, their enumeration, and the database requirements for their maintenance. This is a topic surely to ignite passion. In order to cool folks down, Peter has graciously arranged for me to follow him, and I will present some of our plans from the Joint WEDI/SNIP and AFEHCT ID Routing Special Interest Group. If you're attending the HIPAA Summit next week, please try to take advantage of this opportunity to get a picture of how all the pieces-parts of directories, electronic Trading Partner Profiles, identifiers, and EDI Addresses all will tie together. William J. Kammerer Novannet, LLC. +1 (614) 487-0320
Re: IBM ebXML patent claim
I wouldn't get my undies in a bunch quite yet over this patent brouhaha. The patent really applies to certain usage of the ebXML CPA or Collaboration Protocol Agreement. On Friday, 12 April, 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. I see no reason we shouldn't move full speed ahead in borrowing or stealing stuff from ebXML, including the CPP (electronic Trading Partner Profile) and the Registry. Dale Moberg, chair of the OASIS ebXML Collaboration Protocol Profile and Agreement Technical Committee, has sagely written that ...it is always possible that someone-- not contributing to a specification in the least-- can pull out some software patent that they claim may apply to software implementing the specification. What can standards bodies do in that case? I am afraid that there is a different root problem here, and it lies in the patent review process which has gone a bit wacky. William J. Kammerer Novannet, LLC. +1 (614) 487-0320 - Original Message - From: Rachel Foerster [EMAIL PROTECTED] To: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Thursday, 18 April, 2002 12:59 PM Subject: RE: IBM ebXML patent claim Kepa, Peter, et al, This could be.it will be interesting to see how IBM follows through on this. The howls are extremely loud on the ebXML and UN/CEFACT lists. Rachel -Original Message- From: Kepa Zubeldia [mailto:[EMAIL PROTECTED]] Sent: Wednesday, April 17, 2002 6:51 PM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: IBM ebXML patent claim Peter, Is this theend of ebXML? I hope they change their mind and start offering a royalty free license. In the meantime... Viva EDI! Kepa - Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, 17 April, 2002 03:55 PM Subject: IBM ebXML patent claim Interesting article. http://techupdate.zdnet.com/techupdate/stories/main/0,14179,2861528,00.h tml Peter Peter Barry Peter T Barry Company Independent Consulting Health Care and Information Systems Ozaukee Bank Building 1425 West Mequon Road Mequon Wisconsin 53092 (414) 732 5000 (national cell) [EMAIL PROTECTED]
Re: When is a CH a payer, or provider, for that matter?
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. William J. Kammerer Novannet, LLC. +1 (614) 487-0320 - Original Message - From: Dave Minch [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, 12 April, 2002 04:20 PM Subject: When is a CH a payer, or provider, for that matter? If, as Rachel has suggested, 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...). Have I misinterpreted the regulations? Anyone want to bet that these won't be the most common scenarios initially? Dave Minch TCS Project Manager John Muir / Mt. Diablo Health System Walnut Creek, CA (925) 941-2240
Re: A proposed work plan for this group
I 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. William J. Kammerer Novannet, LLC. +1 (614) 487-0320 - Original Message - From: Christopher J. Feahr, OD [EMAIL PROTECTED] To: WEDI ID Routing [EMAIL PROTECTED] Sent: Friday, 12 April, 2002 05:34 PM Subject: Re: FW: A proposed work plan for this group I would like to make a motion that our proposals be designed specifically to meet the business needs of INDIVIDUAL PROVIDERS wishing to directly communicate with INDIVIDUAL PAYORS. My reasoning: Some of our inability to reach clear consensus appears to be fuzziness about the intended target audience for our address discovery schemes and any best practices recommendations, such as who the ISA receiver should be, bundling transactions destined for different receivers, etc. If our work products are well suited to 2-way communication between little providers and big payors, however, they may also be of interest to middleman entities like VANs and CHs who are interested in creating services for doctors. Given the variety of current business practices among existing middleman-players, however, I think it would be a mistake for this group to attempt to support in our recommendations what these guys are doing today . If we limit our scope as suggested, we will be writing specifications to support a business model that has not yet emerged in the marketplace: lots of small providers sending/receiving directly with lots of individual payors. In fact, massive direct connect EDI may never emerge in healthcare IF the middleman industry does a terrific job of packaging up simple, cost-effective solutions for offloading this headache from the doctors. From the doctors' point of view, they have to PAY SOMEONE to work this magic and they could give a rat's butt whether it was a VAN, a CH, or a $20,000 software upgrade... just so Suzy knows which button(s) to push and they eventually get paid! Comments? Regards, Chris Christopher J. Feahr, OD http://visiondatastandard.org [EMAIL PROTECTED] Cell/Pager: 707-529-2268
Re: A proposed work plan for this group
Rachel: You've maintained that ... the clock is ticking and time is fast running out for this group to provide direction to the industry to solve the immediate problem. You suggest we: 1. [Develop] a clear and succinct statement of the problem(s) to be solved. Prioritizing the identified problems. The careful reader over the last couple of months would have been able to discern the problem(s) - though, admittedly, it would serve everyone better if this stuff were well-organized in the working papers! Doesn't it suffice to say the purpose of the project is to give a consistent (or automated) means of discovering partners and their technical capabilities or EDI addresses? The reason we selected that purpose was to solve problems like how the heck does a provider know where to send standard electronic claims or eligibility requests when all he has is the patient's insurance card? Or, how does a payer know where to send eligibility responses and EOBs back to the provider? Things like that. 2. [Develop] a set of functional requirements that will solve the problems identified using today's tools. Our agreed upon working document topics seem to map onto functional areas; the working documents in process, along with the volunteers corralled to write them, are: -Identifiers (co-authors William, Ron Bowron) -Addresses and delivery channels (co-authors: Dave Minch, Tim Collins, Dick Brooks) -Elements of the WEDi/SNIP CPP (Marcelee Jackson, Dave Minch, Dick Brooks, Chris Feahr) -Discovery of WEDi/SNIP CPPs (Peter Barry, Joe McVerry, Dick Brooks) For example, I would expect the functional requirements for Discovery to appear in the last paper - such things (as we've already discussed ad infinitum) as (1) ability to search by any known ID, (2) redundancy, and (3) security and authentication. Are those adequate functional requirements? Do you think we've anticipated each area, and that four working papers are sufficient to cover the bases? 3. [Transform] the problem statement(s) and requirements into a document that can be provided to the industry fast so that the industry can use it now. When the working papers are completed, they will be edited by Peter Barry - white-paper author Par Excellence - and combined into our Recommendations in the form of a WEDI/SNIP white paper. Peter's trusty little sidekick - me - will probably be roped into assisting. William J. Kammerer Novannet, LLC. +1 (614) 487-0320 - Original Message - From: Rachel Foerster [EMAIL PROTECTED] To: WEDi SNIP 4 (E-mail 3) [EMAIL PROTECTED] Sent: Thursday, 11 April, 2002 12:33 PM Subject: RE: A proposed work plan for this group Sure, you can do whatever you want tothe test will be the acceptance of the marketplace in what you do. Thus, it's vital to keep this in mind, and the factors I mentioned below are all factors of marketplace acceptance. Rachel -Original Message- From: William J. Kammerer [mailto:[EMAIL PROTECTED]] Sent: Wednesday, April 10, 2002 11:16 AM To: Rachel Foerster Subject: Re: A proposed work plan for this group Don't we really get to start fresh considering that most providers haven't done EDI at all? Even Dave Minch's hospital group is new to EDI, so can start fresh with new recommendations. I think that we may not have as big a need as we originally thought to accommodate the old way of doing things. William J. Kammerer Novannet, LLC. +1 (614) 487-0320 +1 (614) 638-4384 (c) +1 (928) 396-6310 (FAX) - Original Message - From: Rachel Foerster [EMAIL PROTECTED] To: 'WEDi/SNIP ID Routing' [EMAIL PROTECTED] Sent: Saturday, 06 April, 2002 02:37 PM Subject: A proposed work plan for this group 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
Why do we flap our lips so much about the ISA Receiver ID?
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. William J. Kammerer Novannet, LLC. +1 (614) 487-0320 - Original Message - From: dalegibbs [EMAIL PROTECTED] To: WEDI ID Routing [EMAIL PROTECTED] Sent: Thursday, 11 April, 2002 02:31 PM Subject: FW: A proposed work plan for this group I have been following this tread for some time and am fascinated over the amount of time being dedicated to the ISA Receiver ID. It really does not matter what the ISA Qualifier and Receiver ID are since they will be used as a key
Re: Why do we flap our lips so much about the ISA Receiver ID?
Dale: 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. In your process step 2, you say a manual process [would be] totally unacceptable. I don't agree. 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. 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. 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? William J. Kammerer Novannet, LLC. +1 (614) 487-0320 - Original Message - From: dalegibbs [EMAIL PROTECTED] To: WEDi/SNIP ID Routing [EMAIL PROTECTED] Sent: Friday, 12 April, 2002 12:14 PM Subject: RE: Why do we flap our lips so much about the ISA Receiver ID? William, I agree with you about using the ZZ in the ISA Receiver ID Qualifier, but from a technical point of view, you could. If you use the NAIC from an insurance card as a key to the CPP to get ISA Receiver ID and Qualifier (among other information), then a ZZ would not be a problem. In fact the ISA Receiver could contain DUNNS, DUNNS+4, FEIN, NAIC, etc. The only requirement should be that the content of the ISA Receiver ID correspond to the code placed in the ISA Receiver ID Qualifier and that both values be consistent with HIPAA IG requirements. Process (assuming everyone is in agreement on CPP/CPA) would be very straight for a provider. 1. Obtain NAIC code from Insurance card 2. Is insurance NAIC already on your system? If no, search CPP directory and extract information (requires providers system to store insurance information and be able to extract it when they create ASC X12 claims document. This will require either a significant update to their current system or new software. The other option would be a manual process which is totally unacceptable) 3. Do we need to create a CPA before submitting any kind of document? How would this work? What is the process? 4. Once CPA created (how long will this take?) Create ISA claim document using ISA Receiver ID and Qualifier extracted from CPP. 5. Send document based on CPP EDI Address requirements Is this the general process we are talking about. Please help me fill in the gaps noted above. Dale Gibbs E-COM Advisor 614.871.2314
I've yet to see any call for special needs on the part of Clearinghouses
Maybe I've missed something, but I've yet to see any call for special needs on the part of Clearinghouses. The only thing that comes close is the assignment of proprietary CH or payer assigned provider IDs, and it looks like nobody really likes them anyway... which is good because we will be much better off with standard IDs like DUNS, FEIN, NPI (when it comes), National Plan ID (in the future, too), HIN, etc. for searching the Healthcare Registry and denoting senders and receivers in the ISA. William J. Kammerer Novannet, LLC. +1 (614) 487-0320 - Original Message - From: Michael Mattias/Tal Systems [EMAIL PROTECTED] To: WEDI/SNIP Listserve [EMAIL PROTECTED] Sent: Tuesday, 09 April, 2002 10:30 AM Subject: RE: Who am I? Sender, Receiver, Intermediary, or just plain Chump? I have followed this thread with some interest, especially the parts about how clearinghouses and service bureaus have special requirements. One word: Folderol. Call me old-fashioned, but it seems to me that if one is going to operate a service then one offers services; and the more service, the greater the price. For example... Service A may allow a provider to submit ALL claims, no sorting, no bundling, no nothing. The service bureau then would consolidate claims for like payers, envelope and submit to the payer(s). Service B on the other hand, may insist the customer (provider) batch up claims by payer; the service then envelopes and sends the batches to the various payers. I would think service B would cost less than service A. But as the customer, I can pick the service for which I am willing to pay. Regardless, I cannot see any case in which special handling of standard addressing because a service bureau is involved enters the equation at either the payer or the provider end: seems to me this is what the service bureau is paid to do. Same on documents from payer (though service bureau) to provider: the service should handle any breakdown/distribution. As a sender (payer or provider) I want to know two things: 1. What is the recipient's EDI Address? (presumptively the ISA segment identifier). 2. What is the recipient's application identifier (GS)? Mr. Payer, Ms. Provider, your EDI address is a service bureau? Fine, as long as it's transparent to me and your other partners. BIAS ALERT: I expect service bureaus and clearinghouses will be my competition, so I am not likely sympathetic to any special needs claimed by these entities. Michael Mattias Tal Systems, Inc. Racine WI [EMAIL PROTECTED] www.talsystems.com
Who am I? Sender, Receiver, Intermediary, or just plain Chump?
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? William J. Kammerer Novannet, LLC. +1 (614) 487-0320 - Original Message - From: Rachel Foerster [EMAIL PROTECTED] To: 'Christopher J. Feahr, OD' [EMAIL PROTECTED]; 'Dave Minch' [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Friday, 05 April, 2002 06:43 PM Subject: RE: Are only 15 characters in the ISA receiver ID enough? Chris, This issue of defining who the real sender and receiver are was brought up early in this list's history. At that time I strongly recommended that a project glossary be developed so that, at least for discussion purposes here, we would have clear definitions of terms. Alas On the other hand, at that time I also did a rather thorough search of all of the HIPAA IGs and throughout all of them there is the consistent intent and use of the sender being either the provider or payer and the receiver being either the payer or provider. Nowhere in any of the HIPAA guides is there a explicit or implicit statement that the sender is just the next hop for the interchange. In other words, the provider and payer are the real trading partners for purposes of the HIPAA transactions, and intermediaries, whether clearinghouses or something else, are just that - an intermediary between the true end-point business partners. Perhaps it's useful to think about the U.S. Postal Service as a metaphor. The address on the envelope is always the end-point receiver, and not the next Post Office facility that the envelope may pass through. This is the model that the X12 interchange envelopes follow as well. Rachel Rachel Foerster Principal Rachel Foerster Associates, Ltd. Professionals in EDI Electronic Commerce 39432 North Avenue Beach Park, IL 60099 Phone: 847-872-8070 Fax: 847-872-6860 http:/www.rfa-edi.com
Re: Are only 15 characters in the ISA receiver ID enough?
Dave: I took a look at my insurance card for Anthem Community Choice, and besides my ID no. and group name, the BC/BS plan code of 332/834 (Inst. vs. Professional) appears on the front. There're also the usual phone numbers, and the claim submission mailing address. So how does a provider (today) know how to go from the respective Blue Cross/Blue Shield plan no. to an EDI Identifier? But I certainly hope *NOT* that the best identifier of all for discovering the CPP is that contact address or phone number... I want the payer or plan EDI identifier to appear directly on the insurance card - in order that things can be automated (without phone calls and paper). Speaking of Plans, Peter Barry presented a paper on Identifiers at the HIPAA Summit West in San Francisco last month. Maybe he can be persuaded to share the paper with the group. But anyway, the impression I came away with is that the National Plan ID will appear on the patient's Health Identification Card - and by using the National Plan ID as a key, you can access the National Plan ID database whence you're cross linked to the entities processing those plans (e.g., payers, employers, Third party administrators). If those cross links were to CPPs, then the National Plan ID database itself would supplant any need for a separate CPP Registry for payers. However, I wouldn't bet the farm on the possibility there would be any government sponsored databases available and running in time for H-day! - even though the HIPAA Funding proposal in the Bush Budget includes $34.5 million to implement a system to assign unique identifiers for providers and health plans. William J. Kammerer Novannet, LLC. +1 (614) 487-0320 - Original Message - From: Dave Minch [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, 02 April, 2002 09:36 PM Subject: RE: Are only 15 characters in the ISA receiver ID enough? If I can sum up the last few days of discussion that I have just waded through: as a transaction sender I should be able to follow the workflow below, starting with the responsible party's insurance card: 1) Copy the payer's identifier information from the card into a query transaction (note there are usually 3 key pieces of information on this card -- Group ID, Plan ID, Group/Plan Name -- and we need to understand which or what combination is copied into the query as well as what the query looks like); 2) Bounce the query transaction off of a DNS to get an electronic address of where the receiver's ebXML-CPP is stored (and, perhaps, learn a little more about the payer like data in Kepa's XML tag example); 3) Create a specifically formatted transaction to query for the ebXML-CPP (I'm still not clear on where the CPP itself is stored - is it in the payer's server, or an independent registry like the ebXML registry, or is Kepa suggesting the entire CPP could be contained in the tag? Clearly, wherever it is, it needs to be kept current, and would certainly be in the best interest of the receiver to keep it so - even without Federal penalties); 4) Take the EDI Address information for the transaction desired and populate the various trading partner fields in my transaction generation software. 5) Generate the transaction. The ISA08 would contain the ultimate interchange receiver's EDI identifier (if I'm the provider and the transaction is a claim, then the address is the payer's), and the other EDI Address information from the CPP would tell me where to route the transaction (payer itself, a third party administrator, CH, etc.) along with the communication details of the actual receiver. It is then up to my transaction generator software to be smart enough to group transactions together into 1 envelop (ISA) when there are multiple claims for the same payer. Following this logic, I would therefor be required to send multiple transactions (multiple ISA/IEAs) for different payers using the same third party admin or CH since ISA08 is the payer's, not that of the initial transaction destination. I must admit that this is a new way of looking at the X12-837 message for me - I was assuming that 1 ISA/IEA going to 1 place (like a CH) would contain all claims going to that location, irrespective of the ultimate destination. I like it - it gives me the added advantage of getting 997 acknowledgements back by payer since they are in separate envelopes, but it requires that I deliver many envelops to the same destination (I don't think this is any great amount of added effort, is it??)... As a transaction receiver, it would be 1 step simpler in that the identifier provided to me in ISA06 would be a unique ID, under which the sender would have listed their CPP. So the steps would be exactly the same for the receiver to respond to a sender, but the identifier used in step 2 would be that found in ISA06. This tells me that there needs to be at least 2, and possibly more identifiers that can be listed in a DNS that all point to the same CPP. If that is the case
Re: Are only 15 characters in the ISA receiver ID enough?
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. They always say a picture is worth a thousand words, but even if I had the requisite career-enhancing Visio or Powerpoint skills, I still wouldn't be able to post an attachment to show this! The DNS directory, to be used for mapping logical identifiers to CPPs, is still very much in the running. Is it flexible and robust enough, though, to accommodate some of the additional twists which may be required - such as searching for CPPs on non-primary identifiers? The ebXML Registry is (supposedly) available today, too, and may have search capabilities above and beyond the DNS directory, with the added benefit that security and authentication is built-in. William J. Kammerer Novannet, LLC. +1 (614) 487-0320 - Original Message - From: Kepa Zubeldia [EMAIL PROTECTED] To: Christopher J. Feahr, OD [EMAIL PROTECTED]; William J. Kammerer [EMAIL PROTECTED]; WEDi/SNIP ID Routing [EMAIL PROTECTED] Sent: Tuesday, 02 April, 2002 04:26 PM Subject: Re: Are only 15 characters in the ISA receiver ID enough? Isn't the small size of these identifiers the main reason why we have to map the identifiers into an address? It is still trivial and reliable and cheap to do this using the currently existing DNS, using a small XML tag in the TXT component of the DNS directory, just like William has his setup. The XML code can point to a URL or a phone number or any other sort of address and specify additional parameters like hours of operation, transactions supported, etc. If we could just agree on one way to do this... It does not have to be perfect. It does not have to be complete. Maybe it does not even need to cover all the possibilities. But it needs to be useful/usable TODAY. Just a thought... Kepa
How can we treat real time as a secondary issue?
If there are payers out there who are running eligibility on a separate system from their claims, then I don't know how we can treat real time as a secondary issue. Right at the start, won't these payers demand some way to say eligibility requests go here, and claims go there? Or do these payers maintain a single EDI entry point which can do the culling and separation - passing inbound eligibility request functional groups on to a real-time process, while batching claims for the third-shift? Should this splitting be the responsibility of the sender (say, the provider) or the receiver (payer)? If the sender, then he's responsible for getting the interchange to the appropriate EDI Address or portal for real-time vs. batch. Otherwise, if we agree the burden should be on the receiver, she has to have one portal and split transactions and route internally. My bias would have been to not put this burden on the sender (provider), as I had pleaded in Re: Batch vs. Real Time transactions (30 January) at http://www.mail-archive.com/routing%40wedi.org/msg00113.html. William J. Kammerer Novannet, LLC. +1 (614) 487-0320 - Original Message - From: David Frenkel [EMAIL PROTECTED] To: 'WEDi/SNIP ID Routing' [EMAIL PROTECTED] Sent: Tuesday, 02 April, 2002 05:46 PM Subject: RE: Are only 15 characters in the ISA receiver ID enough? William, I think you are making an assumption that may not be true in all organizations. Many large payers and Medicaid's run multiple systems that may physically separate claims from eligibility onto separate platforms. I think your assumption is there will be a single translator/communications gateway which is true most of the time. Since Highmark has been in this discussion, how do they currently receive claims and eligibility? At the X12 meetings in Seattle there was a presentation from a large payer that if my memory served me correctly, implied they were running eligibility on a separate system from their claims. I don't intend to downplay the importance of real time issues but maybe it can be a secondary issue for now. Regards, David Frenkel Business Development GEFEG USA Global Leader in Ecommerce Tools www.gefeg.com 425-260-5030
Re: How can we treat real time as a secondary issue?
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? William J. Kammerer Novannet, LLC. +1 (614) 487-0320 - Original Message - From: joe mcverry [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: 'WEDi/SNIP ID Routing' [EMAIL PROTECTED] Sent: Wednesday, 03 April, 2002 02:53 PM Subject: Re: How can we treat real time as a secondary issue? With UDDI and EBXML registries the sender asks the receiver what the receiver can do. The receiver responds with a list of services and the addresses for each service. Hence, the burden is on the receiver in regards to splitting. Joe McVerry American Coders Ltd. POBox 97462 Raleigh, NC 27624 USA 919.846.2014 (voice/fax) http://www.americancoders.com Home Of OBOE - an EDI and EDI/XML Translator and xBaseJ - xBase Database Engine For Java
Are only 15 characters in the ISA receiver ID enough?
Chris: 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? William J. Kammerer Novannet, LLC. +1 (614) 487-0320 - Original Message - From: Christopher J. Feahr, OD [EMAIL PROTECTED] To: William J. Kammerer [EMAIL PROTECTED]; WEDi/SNIP ID Routing [EMAIL PROTECTED] Sent: Friday, 29 March, 2002 08:23 PM Subject: Re: Payers sure do like proprietary provider IDs! Do providers feel the same way? The ISA receiver ID is defined as follows in the IG: Identification code published by the receiver of the data; When sending, it is used by the sender as their sending ID, thus other parties sending to them will use this as a receiving ID to route data to them The definition seems to imply that ISA08 is some sort of an EDI address. But even if you can identify the receiving entity with one of the permitted numbers, it is still likely to have a variety of application-specific or possibly sender-specific EDI addresses... that might change over time. Can interchanges 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? With only 15 characters in the receiver ID, I don't see how we can identify the entity (via DUNS, FEIN, etc.) and have enough room left to fully specify even a unique registry-pointer to the rest of the collaboration details. This fuzziness about what the standard requires in ISA identifiers, combined with the creative uses that Michael Mattias has described is making it hard for me to visualize how anyone could route these messages WITHOUT drilling down into the transactions to get information about the true communicating
Re: Are only 15 characters in the ISA receiver ID enough?
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? William J. Kammerer Novannet, LLC. +1 (614) 487-0320 - Original Message - From: William J. Kammerer [EMAIL PROTECTED] To: WEDi/SNIP ID Routing [EMAIL PROTECTED] Sent: Tuesday, 02 April, 2002 11:51 AM Subject: Are only 15 characters in the ISA receiver ID enough? Chris: 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? William J. Kammerer Novannet, LLC. +1 (614) 487-0320 - Original Message - From: Christopher J. Feahr, OD [EMAIL PROTECTED] To: William J. Kammerer [EMAIL PROTECTED]; WEDi/SNIP ID Routing [EMAIL PROTECTED] Sent: Friday, 29 March, 2002 08:23 PM Subject: Re: Payers sure do like proprietary provider IDs! Do providers feel the same way? The ISA receiver ID is defined as follows in the IG: Identification code published by the receiver of the data; When sending, it is used
Healthcare CPP registry services
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. William J. Kammerer Novannet, LLC. +1 (614) 487-0320 - Original Message - From: Christopher J. Feahr, OD [EMAIL PROTECTED] To: William J. Kammerer [EMAIL PROTECTED]; WEDi/SNIP ID Routing [EMAIL PROTECTED] Sent: Friday, 29 March, 2002 04:19 PM Subject: Re: A Rose By Any Other Name... William, Some of our preferred ID discussions seem to be flipping back and forth between the preferred ID-key for the CPP Registry and the ID that the message receiver would prefer to have in the ISA... one of the items that would be enumerated in the CPP Registry record. If there were several healthcare CPP registry services available (perhaps WEDI would agree to maintain one for HIPAA covered entities), I would think that a good key for an organization's CPP record would be the FEIN. 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. I know I'm supposed to be researching the innards of the CPP being proposed by OASIS (haven't gotten to it yet!), but for our purposes it would certainly need to contain the preferred ISA receiver info for each of the HIPAA transactions, as receivers may want certain transactions sent to different EDI addresses. Is this the general scenario you have in mind, William? -Chris Christopher J. Feahr, OD http://visiondatastandard.org [EMAIL PROTECTED] Cell/Pager: 707-529-2268
Re: Update on CPP effort.
Rachel Foerster put together a good summary of the CPP/A work coming out of ebXML, in her e-mail Requirement for Automated Trading Partner Setup, on Thursday, 14 February, 2002, available in the archives at http://www.mail-archive.com/routing%40wedi.org/msg00205.html. In effect, a CPP is a machine readable Trading Partner Profile, and a CPA is an automatically negotiated Trading Partner *Agreement* between two partners. William J. Kammerer Novannet, LLC. +1 (614) 487-0320 - Original Message - From: Fody, Kenneth W. [EMAIL PROTECTED] To: 'WEDi/SNIP ID Routing ' [EMAIL PROTECTED] Sent: Friday, 29 March, 2002 01:46 PM Subject: RE: Update on CPP effort. I am somewhat new to this listserv. Is there some place I can go to find out what the acronyms CPA and CPP mean? Thanks. Ken Fody Independence Blue Cross -Original Message- From: William J. Kammerer To: WEDi/SNIP ID Routing Sent: 3/29/02 12:22 PM Subject: Re: Update on CPP effort. Dick: Thanks for the update. It looks like we're getting good traction with this ebXML CPP/A stuff! Speaking of the ebXML Registry: yes, Kepa's DNS directory could certainly locate a CPP document containing trading partner information, using one or more identifiers as the key for the search. I always thought that this was more than adequate, not imagining that it would be particularly useful (to payers or otherwise) to do a query to find all the proctologists in the Columbus, Ohio metro area. HIPAA participants will generally already know their trading partner's ID, and the DNS directory seems entirely suited to searching on that ID. 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). William J. Kammerer Novannet, LLC. +1 (614) 487-0320
Re: Payers sure do like proprietary provider IDs! Do providers feel the same way?
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! 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. 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). William J. Kammerer Novannet, LLC. +1 (614) 487-0320 - Original Message - From: Fody, Kenneth W. [EMAIL PROTECTED] To: 'William J. Kammerer ' [EMAIL PROTECTED]; 'WEDi/SNIP ID Routing ' [EMAIL PROTECTED] Sent: Friday, 29 March, 2002 02:01 PM Subject: RE: Payers sure do like proprietary provider IDs! Do providers feel the same way? William: 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. Ken Fody Independence Blue Cross -Original Message- From: William J. Kammerer To: WEDi/SNIP ID Routing Sent: 3/28/02 3:42 PM Subject: Re: Payers sure do like proprietary provider IDs! Do providers feel the same way? 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
Re: Payers sure do like proprietary provider IDs! Do providers feel the same way?
Chris: D B uses the carrot of the DUNS number get you to use their eUpdate service to update your business profile. Since your company is listed, but you do not know your DUNS. they tell you to call 888.814.1435 Monday-Friday 8:00AM-6:00PM local time, or go to https://www.dnb.com/product/eupdate/update1.html to request an eUpdate logon (which is your DUNS) and password to review your company profile. William J. Kammerer Novannet, LLC. +1 (614) 487-0320 - Original Message - From: Christopher J. Feahr, OD [EMAIL PROTECTED] To: William J. Kammerer [EMAIL PROTECTED]; WEDi/SNIP ID Routing [EMAIL PROTECTED] Sent: Wednesday, 27 March, 2002 10:52 PM Subject: Re: Payers sure do like proprietary provider IDs! Do providers feel the same way? William, I did a little poking around on http://sbs.dnb.com/default.asp and I see that Christopher J. Feahr, OD is listed in DB''s database... even correctly listing my two partners, one of whom joined me only a year ago. But I did not see my DUNS number. How does one discover or get assigned a DUNS #? I would think it's automatic if you are in the DB as a business. -Chris BTW: I do find it extremely annoying as a provider to have to maintain so many different IDs for myself for different payors. WHAT THE HECK IS THE HOLD-UP ON THESE NATIONAL IDENTIFIERS FOR BUSINESSES??? I don't see how this could be controversial of very difficult to implement. Christopher J. Feahr, OD http://visiondatastandard.org [EMAIL PROTECTED] Cell/Pager: 707-529-2268
Re: What's the focus?
I gave an update on our objectives to the Business Issues workgroup two weeks ago where I attempted to summarize the results and decisions made on the teleconference and our progress to-date; see my message at http://www.mail-archive.com/business%40wedi.org/msg00280.html. I think the objectives of the group are clearly enough delineated in my message, though if you have suggestions on better organizing the ideas, I'm all ears. Unfortunately, the 6320 EDI Addr Desc Bus Case document has not yet been updated to reflect our new direction and expanded scope. I expect that Peter Barry will have that document updated shortly and we will be able to post it to the ID Routing web page at http://www.novannet.com/wedi/. William J. Kammerer Novannet, LLC. +1 (614) 487-0320 - Original Message - From: Rachel Foerster [EMAIL PROTECTED] To: WEDi SNIP 4 (E-mail 3) [EMAIL PROTECTED] Sent: Thursday, 28 March, 2002 03:45 PM Subject: What's the focus? There has been a wealth of information posted to this list over the last several weeks. But, I'm beginning to be a bit concerned, and possibly, confused (it wouldn't be the first time!) that perhaps the discussion and information exchange has gone a bit off track. In looking at the original business case document for this work group developed by Peter Barry, I believe the following sections should be front and foremost in our efforts: 2.0 Objective of the EDI Address Project This project is to define the syntax of a comprehensive, standard EDI Address, including attributes such as described here, and to define the associated code structure. Its deliverable is intended to have technicalspecificity. 7.0 The Proposed Work This project will pursue the following: *Write technical specifications for syntax and code structure for the EDI Address including its associated attributes. The sequence is to begin with the easier and continue to the more difficult. *Define attribute code tables. *Determine required changes, if any, in X12 and other standard transactions. *Coordinate with WEDI-AFEHCT Health Care Communications Security and Interoperability project. Coordination between the two projects is critical. Have we lost focus? Or have we just not yet determined a focus? As I said in a message in early March, . . .any project must have a clearly stated objective.thus far I'm not sure this group has such an objective or reached consensus on an objective. The first question to be answered, in my opinion is: Does this group wish to embark on a project to develop a technical specification for a health care EDI Addressing System? This is what was posed in Peter Barry's first draft document. William talks about a white paper for EDI Addressing. These two things are substantially different animals. Thus, is the goal of this group to develop: 1. A technical specification for a health care EDI Addressing System or 2. A white paper discussing issues, approaches, challenges for EDI Addressing of EDI interchanges Folks, where are we on the objective for this work group? If the objective is neither 1 or 2, then what is it? Rachel Foerster Principal Rachel Foerster Associates, Ltd. Professionals in EDI Electronic Commerce 39432 North Avenue Beach Park, IL 60099 Phone: 847-872-8070 Fax: 847-872-6860 http:/www.rfa-edi.com
Re: What's the focus?
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). William J. Kammerer Novannet, LLC. +1 (614) 487-0320 - Original Message - From: Rachel Foerster [EMAIL PROTECTED] To: 'WEDi/SNIP ID Routing' [EMAIL PROTECTED] Sent: Thursday, 28 March, 2002 04:55 PM Subject: RE: What's the focus? I'm not sure I understand why the primary focus is only on identifying providers.? I saw nothing in the original business case document that limited the effort to providers only. Rachel Foerster Rachel Foerster Associates, Ltd. Phone: 847-872-8070
Companion Guides as Proprietary Company Confidential Information?
Speaking of confidential and secret stuff, like supposedly, y'know, HIN numbers - where if you even look at one of 'em, your eyes will melt like what happened to that Nazi guy in Raiders of the Lost Ark - I have a correspondent telling me that payers often regard their HIPAA IG companion guides as Proprietary Company Confidential Information. 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? Ronald Bowron pointed us to the Noridian Medicare links, including Noridian's Medicare Part B Companion document, at http://www.noridianmedicare.com/provider/edi/tech_docs_6_hipaa.html. Stuff like this is good for determining the requirements of a mechanized companion guide in an XML format. I would like to collect more sample companion documents so we know all the types of stuff in them - again, can subscribers to this list share theirs? William J. Kammerer Novannet, LLC. +1 (614) 487-0320
Re: Payers sure do like proprietary provider IDs! Do providers feel the same way?
Ken: Your comments are very helpful - thanks for writing in. And it's good to see even payers want a standard provider ID, rather than relying on proprietary schemes. Actually, our group is concerned mostly with the provider ID as used in the sender ID on the ISA, but the same issues probably arise for providers when they're forced to memorize a bunch of payer-assigned proprietary IDs to use within the application transaction set (in the NM1 and REF). Is it safe to assume most payers assign proprietary IDs for each provider location? If so, that argues strongly for using the DUNS+4 system, which can be used to uniquely identify specific locations within a particular company (provider, in our case). The DUNS (Data Universal Numbering System) number itself is assigned by Dun Bradstreet, described at http://www.dnb.com/dunsno/dunsno.htm. Its advantage is that it's *free* - as a matter of fact, you actually have to work to avoid getting one of their numbers, as Dun Bradstreet makes it their business to mind everyone else' business: practically every business in the U.S. has one, whether they want it or not. DB assigns unique 9-digit DUNS numbers to all legal entities - it's a pretty safe bet that every clinic, hospital and practice in the U.S. has been enumerated by Dun Bradstreet and has been assigned a DUNS number. For example, in my e-mail from Tuesday, I showed the DUNS numbers for two hospitals in my hometown, Columbus, Ohio: 04-643-0013 for Children's Hospital, and 07-164-3589 for Riverside Methodist. Its not even big regional hospitals who have DUNS numbers: even little Novannet has one - 07-293-0527. My doctor has one. My dentist has one. My kids' pediatrician has one. I assume anybody who does business has one. So the DUNS seems perfectly suitable as a unique provider ID - at least until the National Provider ID is implemented. Why do people fight it? On the other hand, DUNS+4 is probably a figment of some EDI guy's imagination. It's nothing but the DUNS appended with an additional 4 characters - hence the +4 - defined by the company for their internal locations. The DUNS+4 is basically a unique cookie for identifying internal locations. A way was needed to describe retail store locations which would remain unique even with mergers and acquisitions - so the solution was to append a self-assigned 4-digit store (or dock or building) number to the D B assigned DUNS. The DUNS+4 is used a lot in the grocery business: see how Krogers and SuperValu use the DUNS+4 to identify their warehouses and stores at http://edi.kroger.com/ and http://ec.supervalu.com/Wholesale/wholesale.htm. The 816 Organizational Relationships Transaction Set can be used to tell your trading partners (payers) which DUNS+4 corresponds to a particular (provider) location (e.g., address). You would think it would be sufficient for the provider to enumerate his own locations, assigning DUNS+4 IDs to each, and passing an 816 transaction set to the payer to update the payer's files. All payers would then be using the same provider location number (the provider-assigned DUNS+4), and we should all be happy! Another favorite of mine, the Health Industry Number (HIN), at http://www.hibcc.org/hin.htm, is an analogous attempt at coming up with a uniform method of assigning IDs to specific locations. One advantage of the HIN is that location information is centrally managed at HIBCC, so there's only one place you need to go to in order to obtain all HIN numbers (as opposed to receiving 816s from each provider individually). William J. Kammerer Novannet, LLC. +1 (614) 487-0320 - Original Message - From: Fody, Kenneth W. [EMAIL PROTECTED] To: WEDi/SNIP ID Routing [EMAIL PROTECTED] Sent: Wednesday, 27 March, 2002 11:03 AM Subject: RE: Payers sure do like proprietary provider IDs! Do providers feel the same way? Bill: 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
More Stuff and Questions on Routing Identifiers
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). Can anyone help out here? Am I the only one who thinks the HIPAA IGs use IDs in kind of a loosey-goosey fashion? William J. Kammerer Novannet, LLC. +1 (614) 487-0320
Payers sure do like proprietary provider IDs! Do providers feel the same way?
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? William J. Kammerer Novannet, LLC. +1 (614) 487-0320
Re: HIN numbers: I'll show you mine if you show me yours....
Rachel: Well, we certainly have a little conundrum here. If the HIN numbers can't be divulged to any third party, then how the heck do you think they'd ever be used as identifiers for routing? Doesn't the VAN or Clearinghouse have to see them, and build routing tables containing the HIN of their subscriber? Would the VAN or CH need to have a HIBCC HIN database license also, to the tune of thousands of dollars a year? - even though the subscriber would supply their own number? If your interpretation of the database license is correct - which I don't believe for a moment it is - then the HIN is worthless for our pursuits, and cannot be used for identification of parties on the ISA. Again, the license is for the database HIBCC supplies, not for using individual HIN numbers. But in any case, if you remain adamant on this issue, I will be most happy to see the HIN removed as a proposed identifier in our recommendations, and further, I wouldn't shed any tears if it were expunged from the list of acceptable HIPAA IG ISA Interchange Qualifiers. If your interpretation of the license is correct, with concomitant onerous licensing issues regarding the use of the HIN, it's a wonder it was ever seriously proposed to serve as the National Provider ID - it would have been dead on arrival (to use medical parlance). William J. Kammerer Novannet, LLC. +1 (614) 487-0320 - Original Message - From: Rachel Foerster [EMAIL PROTECTED] To: 'WEDi/SNIP ID Routing' [EMAIL PROTECTED] Sent: Tuesday, 26 March, 2002 05:58 PM Subject: RE: HIN numbers: I'll show you mine if you show me yours Yes, William, there is something that can prohibit the sharing of HINs with 3rd partiesit's the license agreement one signs in order to use and subscribe to the HIN system. That's why I posted that portion of the license agreement. Whether this constitutes copyright or trademark is irrelevantit's in the contract. To wit: Licensee acknowledges that the Data Tape constitutes valuable copyrighted and proprietary information of Licensor. Licensee agrees not to sell or release the Data Tape to any third party and not to disclose any information contained on the Data Tape to any other individual, association, firm, parent or subsidiary organization, or other entity whatsoever, except with the prior written permission of Licensor (permitted disclosure). Rachel -Original Message- From: William J. Kammerer [mailto:[EMAIL PROTECTED]] Sent: Tuesday, March 26, 2002 3:25 PM To: WEDi/SNIP ID Routing Subject: HIN numbers: I'll show you mine if you show me yours I'm no Intellectual Property Lawyer (but my dad was, and my sister and brother-in-law are does that count? - actually I should have been one, too, but Daddy always liked Patty better and... well, we don't want to get into that rat's nest...) but copyrighting crappy little random alphanumeric IDs is the dumbest thing I ever heard of. Sure, HIBCC can copyright the entire database itself, but I seriously doubt there's anything that can prohibit a company from sharing their HIN number with another person or entity. The same thing attends the AMA's Current Procedural Terminology (CPT) Code (44950 means appendectomy... there I did it - go snitch on me!), UCC EAN GLN numbers for manufacturing, SCAC codes for transport, or even Dun Bradstreet D-U-N-S numbers. William J. Kammerer Novannet, LLC. +1 (614) 487-0320
Say, why do you think UDDI sucks?
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. Please see http://www.novannet.com/wedi/ for more information on the WEDi/SNIP ID Routing group, including our listserve archives. William J. Kammerer Novannet, LLC. +1 (614) 487-0320 - Original Message - From: joe mcverry [EMAIL PROTECTED] To: WEDi/SNIP ID Routing [EMAIL PROTECTED] Cc: William J. Kammerer [EMAIL PROTECTED] Sent: Tuesday, 26 March, 2002 02:29 PM Subject: Re: More Stuff and Questions on Routing Identifiers Is there an archive for this list? I seemed to miss the discussion on the merits and demerits of using UDDI? Joe -- --- Joe McVerry American Coders Ltd. POBox 97462 Raleigh, NC 27624 USA 919.846.2014 (voice/fax) http://www.americancoders.com Home Of OBOE - an EDI and EDI/XML Translator and xBaseJ - xBase Database Engine For Java
ebXML Registry
As expected, my introductory e-mail to the OASIS ebXML Registry TC has elicited responses from no fewer than three ebXML Registry software vendors - all these guys are tripping over each other to be the first in line to help us out. I think name-dropping WEDI/SNIP really opens doors. Everybody wants to get in on the Next Big Thing - HIPAA: the best thing that ever happened to EDI. Of course, the Joint WEDI/SNIP and AFEHCT ID Routing group will be happy to work with any vendor on our pilot study for the registry. Say what?!! We haven't mentioned anything heretofore about pilot studies - it just popped into mind: every standards group needs to have self-perpetuating activities planned for the future!! 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. William J. Kammerer Novannet, LLC. +1 (614) 487-0320
Re: [ebxml-cppa] WEDi/SNIP Electronic Trading Partner Agreements for HIPAA
More on our liaisoning efforts with the OASIS ebXML Collaboration Protocol Profile and Agreement TC. The chair, Dale Moberg, has expressed interest in collaborating with us. To demonstrate just how important this stuff is, our man, Dick Brooks, will be meeting Dale sometime near the end of the month for some face time to discuss our mutual interests. 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. By the way, the monthly Archives for the OASIS ebxml-cppa mailing list are available at http://lists.oasis-open.org/archives/ebxml-cppa/. William J. Kammerer Novannet, LLC. +1 (614) 487-0320 - Original Message - From: William J. Kammerer [EMAIL PROTECTED] To: OASIS ebxml-cppa [EMAIL PROTECTED] Sent: Thursday, 07 March, 2002 05:30 PM Subject: Re: [ebxml-cppa] WEDi/SNIP Electronic Trading Partner Agreements for HIPAA Dale: Do you know whether HIPAA/WEDi/SNIP intends to adopt or create a way of specifying business processes? We're not even able to establish formal business collaborations, as HIPAA EDI is very X12 message centric. It doesn't really lend itself to the one-for-one request-response paradigm - except maybe in the case of the eligibility request-response pair (X12 270/271) that might be conducted in real-time. Healthcare administration (HIPAA) EDI has not really established any formalized approach to requirements analysis, use case development, etc., at all. It's just EDI messages back and forth. Unlike the supply chain side of the business, where at least you have a PO Ack to answer a PO, you can't really say an 837 claim (which is a misnomer: the 837 might contain many claims for many providers to a payer, depending on whether aggregation is done by a billing service) even has a single remittance response. See the dialog that goes back and forth about business processes in the thread entitled Re: Requirements Gathering - Information Flows at http://www.mail-archive.com/routing%40wedi.org/ - especially those written by myself or Dave Minch. At this time, I doubt we're going to make much use of the BP specifications - unless someone in BP can help us figure out some way to choreograph the mandated HIPAA X12 transactions! As far as the CPP-CPA is concerned, we're interested in a lot of stuff, like security profiles and policies, including support of both PGP and X.509, signing of the e-TPA, alternative messaging services and packaging for supporting legacy protocols (especially FTP, EDIINT AS1 and AS2, EDI value-added networks and Healthcare Clearinghouses), specifications for payload compression (some X12 837 claims documents can grow to megabytes), and selection of delivery channels depending on the type of transaction to be sent (e.g., batch vs. real-time). We also need mechanized versions of the stuff you'd expect to see in a paper TPA, like EDI contact information. Throw in references to EDI-centric information we use in HIPAA - like machine readable companion documents which augment situational element and segment notes in the HIPAA implementation guides, and notations which indicate which X12 documents are supported (a provider may say he uses 837s, but accepts only paper remittances - he can pick and choose). In addition, the PartyId OASIS URI will have to accommodate those ID domains used in Healthcare: e.g., DUNS, FEIN, HIN, NAIC Company Code, HCFA carrier ID, HCFA Fiscal Intermediary Identification Number, Medicare Provider Number, etc. Even though healthcare claims are processed by value-added intermediaries (such as re-pricers and reviewers), I have no idea whether multi-hop will be applicable to us (even though ebXML MS is a transport option, I doubt it will be used much in the next few years in Healthcare). Is this enough to get a discussion flowing for exploring our requirements? Sorry, but we can't change the X12 flavor of HIPAA - that's cast in concrete by legislation! William J. Kammerer Novannet, LLC. +1 (614) 487-0320 - Original Message - From: Dale Moberg [EMAIL PROTECTED] To: William J. Kammerer [EMAIL PROTECTED]; OASIS ebxml-cppa [EMAIL PROTECTED] Sent: Wednesday, 06 March, 2002 06:20 PM Subject: RE: [ebxml-cppa] WEDi/SNIP Electronic Trading Partner Agreements for HIPAA Hi, We are still wrapping up details connected with 2.0, and we have active commitments to work on: 1. Oasis CPPA Negotiation protocol 2. BTP role capability and agreement representation. All other
Re: How's EDI accomplished in HIPAA?
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. This Special Interest Group in WEDi/SNIP is developing new recommendations for the auto-discovery of trading partner information - including communication protocols and addresses. These recommendations may someday make it easier for your automated software - or *your* clearinghouse - to discover that payer X is reached via a particular Clearinghouse B, or at a particular FTP or SMTP e-mail address. In the meantime, you may find that posting to the WEDi/SNIP Business Issues or Transactions listserves will be more fruitful in obtaining practical answers for current practice. William J. Kammerer Novannet, LLC. +1 (614) 487-0320 - Original Message - From: Luis E. Cotto [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, 06 March, 2002 09:16 AM Subject: How's EDI accomplished in HIPAA? Hi! My name is Luis Cotto. I'm currently working as an IT Advisor for a Health Service Provider in Puerto Rico. I'm interested in obtaining more information regarding how the data is transferred from one system to another. I understand how the data translation between each standard is more or less going to be done but I don't understand clearly how is this data transferred, for example, from my client to another Provider, etc. Is this done by a direct dialup line, through Internet? How's the EDI supposed to be implemented regarding the HIPAA law? Please advice. Thanks!
Trading Partner Agreements
Marcallee Jackson has graciously offered to start the ball rolling on Trading Partner Agreements - or, more correctly, how to avoid the paper versions of them. As you'll recall from previous discussions, sometimes the manual EDI enrollment processes and concomitant paperwork are so complicated and take so long that providers are sometimes unwilling to undertake the hassle, especially if their volume of claims to a particular payer is relatively low. That means more stuff is dropped to paper when one or more of the parties can handle electronic transactions. Though the legal issues behind TPAs are - strictly speaking - not really in our charter, the consensus seems to be that if it takes 2-8 weeks to get the paperwork done for electronic trading, it would surely throw some cold water on the ideal of providing automatic and instantaneous means of discovering EDI addresses! To see just what hassles a paper TPA entails for Clearinghouses, see Marcallee's posting from 20 February, 2002: 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. Marcallee has arranged to have some legal folks she knows help us out in determining TPA requirements under HIPAA (if any). Right now, we have Marcellee, Dave Minch and Rachel Foerster from our group working on this effort. We do already have representation from the Clearinghouse, Big Provider and CMS perspectives. But there's still room for someone from the Big Payer side of the house to help out - especially a Big Payer who insists on paper TPAs and enrollments. If you're a Big Payer, would you volunteer by writing or calling me privately? Marcallee believes the scope of this effort would entail: 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. Please also remember: we have a WEDi/SNIP ID Routing teleconference scheduled for Friday March 8, from 1:30 - 2:30 EST, 703-736-7290, pin #1315331. William J. Kammerer Novannet, LLC. +1 (614) 487-0320
Proposed Changes to the 6010 ID EDI Address Project Org Document
It looks like we have a second, from Chris Feahr, to broaden the Project Purpose - so it more clearly indicates we're to build a specification for automatically discovering Electronic Trading Partner Agreements (e-TPA) which can be used to mechanically configure communication and translation software. So moved. Now that this change is out of the way, it only seems appropriate that we put forward some additional changes to the 6010 ID EDI Address Project Org Document to make the new Project Purpose happen. For the existing document, see http://www.novannet.com/wedi/. Perhaps the Organization of the Project (Section 4.) needs to be changed around a bit to be more project focused, revolving around the production of working papers - right now we have the amorphous Identifiers and EDI Address Subgroups. Since no ideas on particular Working Papers have yet been proposed, I thought I might throw out a couple of my own suggestions which will give us something concrete to start on. These suggested Working Paper topics were garnered from the questions I asked in Just what is it we're supposed to be doing?, on 26 February, 2002: (1) Interchange Identification and Routing Interoperability: How do you identify the sender and receiver of a standard transaction on the ISA? How can the ISA be addressed in a consistent way so interchanges can be delivered via intermediaries like VANs or CHs, or point-to-point? (2) Trading Partner Identification: Who are the trading partner entities involved in exchanging standard transactions? and what kind of identifiers are available for describing these entities? (3) EDI Addresses and Delivery Channels: How do we specify the destination technical address and its attributes? Now do you specify type of security - e.g., login and password? How would you accommodate scripting? How do you describe the multi-hop path traversed between trading partners through intermediaries and business associates? How do you describe the different in-boxes used depending on transaction type? What do you have to know about a trading partner's technical capabilities before you can send them a standard transaction? What information does a Trading Partner Agreement contain to answer any of these questions? What sort of communication protocols are in use today that need to be supported? and what sort of packaging techniques are used? (4) Electronic Trading Partner Agreements: Can a Trading Partner Agreement be made into a machine-processable form? Can we use the ebXML CPP? If not as it stands, then what changes would be needed to the CPP? Should we consider our own XML version of an e-TPA? How would EDI Addresses and Delivery Channels be represented in the e-TPA? Can an e-TPA completely supplant the need for paper TPAs? (5) e-TPA Discovery: How might electronic TPAs be automatically discovered for your trading partners? If we need a directory for discovery of Trading Partners, will UDDI or the ebXML RegRep suffice? If not, can we devise our own? Who would maintain it? (6) Application Identifiers: What's the relationship between the payer, plan and contract application identifiers and the identifiers used in the ISA? We need volunteers for the Working Papers. As Ben Stein would have said in Ferris Bueller's Day Off - anyone... anyone...? And please remember: we have a teleconference scheduled for Friday March 8, from 1:30 - 2:30 EST, 703-736-7290, pin #1315331. William J. Kammerer Novannet, LLC. +1 (614) 487-0320
We have another volunteer! - this time for the e-TPA auto-discovery code using the DNS Directory
This is a great message!! Dick, thanks for writing in! It always gets peoples' juices running when they can see real live implementations. I take your good news to mean that you're basically volunteering to develop the DNS lookup code? - if it's open, then it can be made a non-normative part of our specifications for the good of the HIPAA community! I 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! William J. Kammerer Novannet, LLC. +1 (614) 487-0320 - Original Message - From: Dick Brooks [EMAIL PROTECTED] To: William J. Kammerer [EMAIL PROTECTED]; WEDi/SNIP ID Routing [EMAIL PROTECTED] Sent: Saturday, 02 March, 2002 04:28 PM Subject: RE: Twenty-second elevator Pitch as Project Purpose in the 6010 document William, Just to give you an update on the progress to date regarding the CPP effort. As you know Systrends has developed an ebXML Message Service Handler that is being used within the Energy Industry. The MSH consists of two parts, a server and a client. The client and server exchange encrypted and digitally signed files over a SSL/HTTP channel using an ebXML based reliable file exchange protocol. This protocol includes the ability to exchange trading partner profile (CPP) data in order to automate trading partner setup. Setting up a trading partner is easy using this method, during installation the client software prompts the user if they want to setup any trading partners. If yes, the user is prompted for an identifier (PLANID or PROVIDERID) and a DNS lookup against Kepa's system returns the appropriate HIPAA information (pointing to a CPP). The client software retrieves the CPP and automatically inserts the CPP information into the clients local database. After the trading partners CPP record is inserted the client software posts their CPP information to the trading partners site for automatic inclusion in their database. Last week I asked the engineering team to investigate what it would take to implement the functionality described above into our existing ebXML MHS. The good news is, the DNS part is trivial, good work Kepa. The CPP part is a good bit of work, but not earth shattering. We have a first cut of the CPP defined, but it's not ready to show yet. I'm hoping to have a demonstration of the client software ready to show at the next X12 meeting, in Minneapolis this June. Kepa, I want to chat with you in the next week or so to see if we can add some additional information to the HIPAA element returned by the TXT lookup. In summary, I know I've been quiet on this list, but I assure you, I have been following the discussions closely and I hope to have working code ready to show everyone shortly. Regards, Dick Brooks Systrends, Inc 7855 South River Parkway, Suite 111 Tempe, Arizona 85284 Web: www.systrends.com http://www.systrends.com Phone:480.756.6777,Mobile:205-790-1542,eFax:240-352-0714
Re: Twenty-second elevator Pitch as Project Purpose in the 6010 document
Chris: Yes, that sounds like a *great* idea! We should make the notion of electronic Trading Partner Agreements - and their discovery - the centerpiece of our project. The 20-second elevator pitch could simply be incorporated as the Purpose of our project in the 6010 document. It's called an elevator pitch because the vision should be expressed in a single paragraph - about the typical attention span of a busy executive as she is waiting to get on or off the elevator. Remember: executives have to conserve their brain cells for really important things - like the color scheme in the board room. And as evidenced by the late Enron execs, not many of them are a Kepa or a Bill Gates: you clearly can't inundate them with too many details about business or technical issues. So I propose to change the wording of Section 1 (Purpose of the Project) to read something like: 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. Even that might be too technical, but it's a start, and emphasizes that we're looking at the bigger picture than simply identifiers and EDI Addresses - even though they are an important part of any e-TPA. This still leaves it wide open enough to incorporate parts of the ebXML CPP for use as the e-TPA. We need to figure out the details of what's needed to be added or changed in the existing CPP. We will ask the OASIS ebXML CPP-CPA team if they would work with us to see what's necessary to support the HIPAA scenarios involving legacy protocols and packaging. Dick Brooks is taking the lead in this, but it certainly sounds like you are interested in this stuff, too, so please join in! If the ebXML CPP people can't help us out with the imminent (within the year) needs of the Healthcare community, then we had better start working on our own e-TPA - though I suppose we would want as much compatibility as possible with whatever is going on in ebXML. William J. Kammerer Novannet, LLC. +1 (614) 487-0320 - Original Message - From: Christopher J. Feahr, OD [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Friday, 01 March, 2002 09:10 PM Subject: Re: Twenty-second elevator Pitch William, Should we try to write out your 20 sec. elevator pitch as an introduction to a working paper? It seems as though you are suggesting shifting the scope to e-TPA structures. Some of the attributes of the EDI address do seem to belong in the TPA, so this would make sense... I'm just trying to keep up! -Chris Christopher J. Feahr, OD http://visiondatastandard.org [EMAIL PROTECTED] Cell/Pager: 707-529-2268
Twenty-second elevator Pitch
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. William J. Kammerer Novannet, LLC. +1 (614) 487-0320
Re: Repricers, Reviewers, Third Party Administrators, etc. -- why we (providers) are concerned
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)? What are we expecting out of the auto-routing capabilities of the electronic Trading Partner Agreement? Even if you had an e-TPA organized by plan, how would you locate it via Kepa's DNS directory, which is organized by entity (e.g., payer)? You would have to know ahead of time which payer handles your plans before you could find the payer's e-TPA for locating the EDI front-doors, wouldn't you? What happens when the employer directly manages its self-funded plans without the assistance of a Third Party Administrator? How could standard transactions be addressed? If the DUNS were used through a VAN, could claims end up going to the same place as supply chain stuff? Is this where the DUNS+4 would come in? - to address the EDI gateway specifically at the HR department? What am I missing here? How does a CH do it? Help me out here. I'm out of my element. Dave Minch mentioned Re-discovery, which I took to mean: how do you figure out whether the electronic Trading Partner Agreement has been updated? This could be done using a date-time stamp in the XML file for the e-TPA itself, or in its filename, pointed to by Kepa's DNS directory. Or maybe we could place something (a serial number?) in the DNS node TXT record, which supposedly is propagated to all local name servers on a regular basis - then without having to retrieve the XML file, you could still tell whether anything has possibly been changed in the e-TPA. This is a problem to put on the To-Do (i.e., Rachel's requirements) list. So many questions. So little time. And whatever white paper we come up with will be in really sorry shape if we don't start getting some answers and feedback! William J. Kammerer Novannet, LLC. +1 (614) 487-0320 - Original Message - From: Dave Minch [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Wednesday, 20 February, 2002 08:23 PM Subject: Repricers, Reviewers, Third Party Administrators, etc. -- why we (providers) are concerned William, 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
Re: Submitter/receiver
See the message, below, posted to the Transactions listserve. Even though Raj is probably referring to the confusing Loop ID-1000 in the 837 (Submitter and Receiver), his question has implications for use of the ISA sender and receiver fields for each hop from provider to repricer to payer. William J. Kammerer Novannet, LLC. +1 (614) 487-0320 - Original Message - From: Thuppanna, Raj [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, 22 February, 2002 06:22 PM Subject: Submitter/receiver I have a question about submitter/receiver in a re-pricing model. In this example, we receive the claim for re-pricing. We are not destination payer. According to 837 IG in the scenario where a provider (or providers billing service) sends the electronic claim to us for re-pricing, the provider is the submitter and we are receiver. We then re-price the claim and forward it to destination payer. Who should be the submitter and receiver when we forward the claim to payer? My understanding based on IG is that submitter and receiver should remain same when we forward the claim to destination payer. But It doesn't make sense for us to be receiver here. In the same model, it we get a paper claim from a provider and then forward the re-priced claim, who should be submitter and receiver? My understanding is that we are the submitter and destination payer is the receiver. Any help is appreciated Thanks Raj Thuppanna 770 444 4468 ** To be removed from this list, send a message to: [EMAIL PROTECTED] Please note that it may take up to 72 hours to process your request.
Re: Interesting Information about the ebXML CPP/CPA Specification
I'll just reiterate and second Rachel's recommendation that we at least look at the ebXML CPP/CPA specification in order to avoid reinventing the wheel. As I wrote last Saturday, 16 February, ...we have the capable Dick Brooks looking into the matter of using the ebXML CPP. He also tells me there are compelling reasons to go with ebXML Messaging Services (which as of this date is the only packaging technique supported by a CPP), not the least of which are (1) the cost of client side software is very reasonable (maybe even *free*), and (2) It will include automated trading partner setup features! For more information on the ebXML CPP, please go to OASIS at http://www.oasis-open.org/committees/ebxml-cppa/. In order to save poor Rachel the trouble of distributing Marty Sachs' presentation, you can fetch it yourself by going to Face to Face Presentations under Documents, and the select ebXML version 1.0 CPP-CPA.pdf. William J. Kammerer Novannet, LLC. +1 (614) 487-0320 - Original Message - From: Rachel Foerster [EMAIL PROTECTED] To: WEDi SNIP 4 (E-mail 3) [EMAIL PROTECTED] Sent: Saturday, 23 February, 2002 06:52 PM Subject: Interesting Information about the ebXML CPP/CPA Specification This group has been exploring various aspects of EDI Addressing, among them the requirement (at least for now) to be able to automatically establish the addressing/transport and other requirements for EDI messaging. I've mentioned several times that the ebXML Collaborative Partner Protocol and Agreement be looked at and perhaps adopted for health care rather than re-inventing this. Marty Sachs of IBM, who was the original ebXML team lead for the development of these specifications, developed an overview of the CPP/CPA specifications in an easy-to-understand presentation format. The overview of the specification capabilities seems to me to satisfy most, if not all, of the various needs that have been expressed by participants on this list. These specifications are now under OASIS for ongoing support and development. Of special interest to this group is page/slide 22 which highlights the CPP/CPA capability to dynamically select a delivery channel for specific message types and then to statically bind that delivery channel to the specific message type. If anyone is interested in receiving this overview - it's in .pdf format - please email me directly to request it since this list does not allow attachments. Rachel Rachel Foerster Principal Rachel Foerster Associates, Ltd. Professionals in EDI Electronic Commerce 39432 North Avenue Beach Park, IL 60099 Phone: 847-872-8070 Fax: 847-872-6860 http:/www.rfa-edi.com
Electronic Trading Partner Agreements
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. William J. Kammerer Novannet, LLC. +1 (614) 487-0320
Re: Electronic Trading Partner Agreements
Can David Frenkel elucidate those things in a TPA that are of interest to lawyers? Could a general purpose, or default, TPA be devised that applies in the absence of a signed contract? - one that says the electronic version is good for all that ails you? Failure to take claims into adjudication and such are practically going to be criminalized under HIPAA, so what's the point of a private contract unless it were to spell out (additional) legal remedies? What if you needed a contract every time you bought a donut, newspaper or coffee? - or checked into a hotel? - that's right: commerce would grind to a halt. That's why laws and the U.C.C. have evolved over time to take care of these (default) issues. If all contingencies that the lawyers are interested in were codified into the HIPAA rule, then there might be a clean way to avoid separate contracts and TPAs. That may not solve the problem entirely, though: I once had a lawyer who insisted on copying - wholesale - entire sections of the Ohio Revised Code into agreements (I and the other party were both in Ohio, by the way, and presumably subject to its jurisdiction), as if this guy got paid by each Wordperfect edit. Are there any lawyers on this listserve listening who would be willing to help out? ebXML has their own resident lawyer, James Jamie Bryce Clark, General Counsel of McLure-Moynihan Inc., who has been eminently helpful to the ebXML Business Process Group. Does anyone know of a lawyer who wants to do some similar pro bono (Italian for free) work here? William J. Kammerer Novannet, LLC. +1 (614) 487-0320 - Original Message - From: David Frenkel [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, 20 February, 2002 10:55 AM Subject: RE: Electronic Trading Partner Agreements Ron, I don't think the TPA process works well today given that every legal department has a different flavor and it is a legal contract. Many legal departments may not want to loose control over this. Regards, David Frenkel Business Development GEFEG USA Global Leader in Ecommerce Tools www.gefeg.com 425-260-5030
Re: Electronic Trading Partner Agreements: Transitivity
Rachel said that COTs (or, really, COTAs - Chain of Trust Agreements) are really out of scope since they actually pertain to the Security NPRM. And besides, they are agreements between business associates themselves, and between BAs and covered entities (payers, providers and Clearinghouses). I'm guessing a COTA would not be required directly between a payer and a provider (or payer and a CH) since, as covered entities, they are all required to be careful with protected health information. Everybody else coming into contact with PHI can freely disseminate it to the wind, unless otherwise covered by a COTA! When I said COTAs were transitive, I just meant that there was no need to have a COTA between A and C, using B as an intermediary, if there were already a COTA between A and B, and another one between C and B (I'm assuming COTAs are also associative). A Trading Partner Agreement, on the other hand, is by definition *between* trading partners - the end points - i.e., a payer and a provider, a payer and a bank, an employer and a payer, etc. But I suppose TPAs could be (somewhat) transitive too: maybe a CH could say if you sign up with us, you agree to certain common criteria and remedies, and to use the standard WEDi/SNIP Electronic Trading Partner Agreement accessible through Kepa's DNS directory. The only signed contract (strictly speaking, not a TPA) in this case would be between the CH and its customer (the payer, provider or yet another CH). This is the same transitive model used in the credit card business: I have (1) a signed agreement with my bank, and (2) my bank has a member agreement with VISA, (3) likewise, my merchant's bank has a member agreement with VISA, and (4) the merchant's bank has an agreement with the merchant himself. Add in some law, like Regs. E and Z, and you have an efficient system that obviates any need for a separate agreement between me and every merchant with whom I use my VISA card. William J. Kammerer Novannet, LLC. +1 (614) 487-0320 - Original Message - From: Ronald Bowron [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, 20 February, 2002 10:32 AM Subject: Re: Electronic Trading Partner Agreements William, I agree with your assessment that manual TPA's would render any automated routing methodology moot. I had previously raised the question as to why the TPA cannot be transitive like the COT? Better yet, why not combine the COT with the TPA? Then the COT/TPA assumes the Payer trusts the Clearinghouse or Repricer to ensure the validity of the Provider (Each CE carries the trust from the previous entity). Not being a legal person, I don't know if this would be advisable or not. There are Provider Credentialing services out there that will substantiate the licensing of an individual provider, as well. I believe the infrastructure exists today, although it is not coupled with the electronic transaction processing, and most likely not well supported by the electronic processing systems. If we could define the methodology for verifying the identity of a CE as part of the TPA process, then the TPA may be able to be automated. I've always advocated, if a manual processing works then consider automation. If it's broken and you automate - you exacerbate the problem 10,000 times more often. So, is the current manual TPA process working well enough that it is possible to introduce automation and standards? Have any of the larger payers moved to a Web Based TPA process? Would a notary model like Thawte (www.thawte.com) is using for certificates be acceptable, or overly complicated? So many questions, so little time. I believe Kepa has the appropriate approach to solving the lower level routing issues, but now we need to walk that back into the business process level and see what falls apart. If business requirements dictate a TPA between CE's before routing can occur, then we must address how TPA's can support our efforts to automate routing. Regards, Ronald Bowron
Re: Small Provider Software Vendors: Certification.
I can see software vendors wanting to say that they're HIPAA certified. That's a great selling point - even if certification is not mandated by law. You as the doctor/practitioner want to have some assurance that your software vendor can generate compliant transactions (either onsite within your licensed software or at the vendor's site). That little holographic label (the one saying HIPAA certified for ODs!) on your software box would give you, presuming you're an OD, some peace of mind that you're not dealing with some fly-by-night software vendor who could be responsible for holding up your claim payments. But when push comes to shove, I believe the payer has to take your purported standard transactions (whether you write the software yourself or use an off the shelf package) - no ifs, ands or buts. And if they're not compliant standard transactions for some reason, I have to believe the payer will have to return you something (an 824 or an e-mail) promptly which clearly indicates at least where the first problem was found. So even if you didn't subscribe to a testing and certification service, you could still manage to have the payer do your debugging for you - as long as you wanted to wait for your payment! Of course, this is an issue for the WEDi/SNIP Testing Group and is none of our business. ...if the doctors can get their own interchanges to the payors, then it stands to reason the payers should have to return the responses through some standard channel other than a mail drop-box on the payors server. Why shouldn't the payer have to use the same means of discovering where the provider is - say, Kepa's DNS directory? If the provider has said he takes e-mail'ed standard transactions as S/MIME attachments encrypted using this here certificate, that seems like a fairly standard and cost-efficient means of returning acknowledgements and responses. Forcing each provider to go through hoops polling an untold number of payers' web sites to access a drop-box seems like an impediment to frictionless e-commerce and an extra cost providers can do without. Where have I heard that before? Power to the little people! Just call me the Huey Kingfish Long of EDI. William J. Kammerer Novannet, LLC. +1 (614) 487-0320 - Original Message - From: Christopher J. Feahr, OD [EMAIL PROTECTED] To: William J. Kammerer [EMAIL PROTECTED]; WEDi/SNIP ID Routing [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; Scott Bussinger [EMAIL PROTECTED] Sent: Sunday, 10 February, 2002 02:45 PM Subject: Re: Small Provider Software Vendors: Clearinghouse or mere business assoicate? I don't think there is any doubt that the vendor would make himself a covered entity/CH if he was constructing the transactions and building the interchanges for his doctor-clients. But I don't really see this as any more onerous for the vendor... In for a penny, in for a pound. If the vendor isn't building error-free interchanges based on the information streaming in from his doctors, then his doctors are still going to expect him to have written the software to accomplish this effectively by remote control. If the doctors and staff members are the ones actually pushing the buttons and creating the messages, then are we going to be able to certify Acme OD Manager software as tested and certified HIPAA compliant... or will we have to certify each office using the software? I don't know why a software vendor would not want to offer a centrally managed [true CH] model to his doctor-customers. But to be fair and inkeeping with the letter of HIPAA, he needs to also provide a theoretical point-to point path for the doctor to the payor (and possibly back again). Even if the doctors can get their own interchanges to the payors, the return paths will not be easy for payors to figure out... leaving them little other choice than the mail drop-box on the payors server option described by Peter as essentially unfair for the provider. When the process matures to the present level of email routing, we *may* see providers (and payors) unplugging from these CH-agents and going direct. But then direct is only an illusion and at the end of the day, I really think doctors would rather not worry about this crap... and get a monthly bill! (But then you do have nutty doctors doing their own electrical wiring... I'm one of them!) Regards, Chris
Seattle X12 Meetings
Due to the amount of interest that the topic of EDI IDs and routing has generated, there is a possibility that more time for a Face-to-Face discussion at the Seattle X12 Trimester meeting will be needed. We have tentatively scheduled discussions to occur in the X12N/TG3/WG2 Transaction Coord. Modeling/Healthcare Modeling Information Forum on Tuesday, 02/05 at 1:00 - 3:00 PM. There is a now a possibility this meeting will be convened earlier that day. So please check the announcements bulletin board in the registration area under X12N for last minute schedule changes. William J. Kammerer Novannet, LLC. +1 (614) 487-0320 +1 (614) 638-4384 (c)
Re: TPA's
Fortunately, we're not burdened in this sub working group with having to answer the question whether individual trading partner agreements are required to be executed by each possible provider-payer pair. But it is definitely an interesting discussion, so I'm looking forward to seeing more of it - and its resolution - on the general Business Issues listserve! Certainly, HIPAA itself doesn't mandate TPAs, does it? Because, surely, that would be an impediment to administrative simplification - it would just be simpler to send paper claims where the volume doesn't justify the horrendous costs of executing a pairwise agreement. Ronald Bowron quoted a snippet out of the final rule: we interpret HIPAA to mean that a health plan cannot refuse to conduct a transaction because it is a standard transaction, . A payer requiring an onerously expensive TPA ($50??!! -that's a bigger money making racket than the residential real estate appraisal business) before it accepts a standard transaction could be construed as refusal, couldn't it? Why would an electronic claim need to be covered by a TPA when a paper claim (containing the same information) wouldn't? - is it because each electronic transaction would be missing the signature, as if doctors really sign these things themselves? As Rachel has said, [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. William J. Kammerer Novannet, LLC. +1 (614) 487-0320 - Original Message - From: Rachel Foerster [EMAIL PROTECTED] To: WEDi SNIP 4 (E-mail 3) [EMAIL PROTECTED] Sent: Monday, 28 January, 2002 12:55 PM Subject: FW: TPA's -Original Message- From: Marcallee Jackson [mailto:[EMAIL PROTECTED]] Sent: Saturday, January 26, 2002 8:21 AM To: [EMAIL PROTECTED] Subject: re: TPA's I'll be bringing the issues of TPA's back to the BI work group. I hope the group will choose to address this topic ASAP. Payer to provider TPA's, required even when there is no direct connectivity between the two, will cause the labor costs associated with EDI enrollment to sky rocket. I'm certain that payers who do not require this today (and the vast majority of payers do not) will incur very significant costs to develop and support the process. Clearinghouses most often facilitate this process by managing forms distribution, provider support, routing agreements to the payer, follow-up and approval notification. Today, providers using a clearinghouse must complete enrollment paper work (TPA's) for 3 or 4 payers. If this number jumps to 25 or 30 a clearinghouse could see its enrollment costs as much as tripling. Eventually, this cost will likely be passed on to the provider who will add new fees to their own internal costs of completing 25 - 30 proprietary agreements. Already one vendor who has an exclusive agreement with one clearinghouse has begun to charge $50 per physician per agreement. For one of my clients, the total charge was over $8,000. This enrollment process is also one of the greatest obstacles to a swift implementation. Most Medicare and Medicaid plans take 6 to 8 weeks to complete the process. That's after the clearinghouse spends 4 - 6 weeks getting completed paper work from the provider. How many weeks will it take when every payer asks for a TPA? I'm looking forward to working with other SNIP participants to find a better way to handle this. Marcallee Jackson Long Beach, CA 562-438-6613
Batch vs. Real Time transactions
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? William J. Kammerer Novannet, LLC. +1 (614) 487-0320 - Original Message - From: Rachel Foerster [EMAIL PROTECTED] To: 'WEDi/SNIP ID Routing' [EMAIL PROTECTED] Sent: Saturday, 26 January, 2002 11:13 AM Subject: RE: Whose name is it, anyway? - and just how many do you think I have? William, The determination of a batch versus real-time use of the 270/271 or the 276/277 cannot be determined by the GS segment, nor even anything within the ST/SE envelope either. The Functional Group ID for these transactions is the same regardless. Rachel Foerster Rachel Foerster Associates, Ltd. Phone: 847-872-8070 -Original Message- From: William J. Kammerer [mailto:[EMAIL PROTECTED]] Sent: Friday, January 25, 2002 5:51 PM To: 'WEDi/SNIP ID Routing' Subject: Whose name is it, anyway? - and just how many do you think I have? There are only so many IDs that an entity might have - what if a Payer only has (one) NAIC that it publishes as its EDI ID, and refuses to use its D-U-N-S or FEIN? Isn't the purpose of the interchange (test, production, real-time) a separate issue from the ID of either the receiver or the sender? I realize many people feel queasy about using the ISA I14 Usage Indicator (e.g., P for Production Data, T for Test Data) to indicate whether an interchange is batch or production, but surely it is overloading the ISA receiver ID to burden it with the duty of segregating test from production. Further, I would be loathe to burden the sender with the need to pick ISA receiver IDs from a list depending on whether the interchange is batch or real-time. Why should a provider have to make that decision - to select the appropriate receiver ID arbitrarily imposed by the payer for a particular purpose - when the function of the interchange can be readily determined by the payer? For example, the payer can discern that real time transactions, like the Eligibility Request, are included in the interchange simply by looking at the functional group ID on the GS. William J. Kammerer Novannet, LLC. +1 (614) 487-0320 - Original Message - From: Rachel Foerster [EMAIL PROTECTED] To: 'WEDi/SNIP ID Routing' [EMAIL PROTECTED] Sent: Tuesday, 22 January, 2002 01:59 PM Subject: RE: Whose name is it, anyway? William, Additionally, payers may wish to use more than one ISA id for different business purposes: one for trading partner implementation testing; another for when the TP is rolled into production; another for real-time processing, and so. Thus, I concur with your conclusion that the payer should establish their ISA id(s) and make these publicly available. Rachel Foerster Rachel Foerster Associates, Ltd. Phone: 847-872-8070
Re: Time-out for terminology question(s)
Chris: (1) I don't really think it matters who the sender (ISA06) is identified as, whether the actual doctor (or clinic) or the business agent (billing service?). The sender ID in the ISA is probably not going to be used in any adjudication decision. It's definitely the ID of the route to which the payer would return technical acknowledgments like the 997 and the 824. But is it the ID to which 835s are sent? Regardless whether the standard claim was generated in the clinic's business office or by the Business agent (or Clearinghouse) a *consistent* sender ID should probably be used. Note that in the scheme of things, it could end up that the provider's ID is an alias of the business agent's ID (in that routing information is identical in whatever global directory eventually exists, or in the CH or VAN routing tables). Rachel would probably insist ISA06 be the ID of the actual clinic or billing provider - and that the BA would only create a transaction specific to that clinic. But what's really wrong with the BA using his ID in ISA06? From what I'm gathering in these threads, it's common for BAs to bundle claims from multiple clinics to a single payer - so obviously any particular clinic's ID shouldn't be used as the sender; instead the sender (or submitter) would be the agent, and his ID would be used in ISA06. The agent would receive technical acknowledgements. But would the agent receive the 835? Maybe the payer, rather than having to worry about which BA handles which provider, would simply use the payee's (the provider's) ID in the ISA receiver field - ultimately, the provider's ID would point to none other than the route to the BA (aliasing), and the 835 would end up where it belongs! Does anyone know if loop 1000 in the 837 (see Chris' question 3) was meant to be used to determine whom the 835 is to be sent? (2) Assuming that any particular claim (837) is intended exclusively for a single payer, it would make sense that the payer's ID would be in the ISA receiver field (how would provider, using standard transactions, know otherwise?), though in reality, the route for that payer ID could deliver the message to the payer's agent. Some things Bob Poiesz has said: [the] 837 allows for one transaction to contain claims for multiple payers, and the 837 transaction is capable of containing claim information for many different payers, means the 837 would not go to a payer (before it was further munged). I would like to see some detailed scenarios here - can anyone help? (3) I don't understand Loop-1000. But I didn't go any further in reading it after I read the submitter and receiver concepts are difficult to define accurately. I'm working a lot on the assumption that providers who chose to do standard transactions should not have to worry about putting any but the payer's ID (which they obtained from the patient's insurance card) in the receiver ID. It shouldn't be his problem to figure out who the payer's business agents are, if any. That's job of the VAN or CH. William J. Kammerer Novannet, LLC. +1 (614) 487-0320 - Original Message - From: Christopher J. Feahr, OD [EMAIL PROTECTED] To: WEDi/SNIP ID Routing [EMAIL PROTECTED] Sent: Thursday, 24 January, 2002 12:11 AM Subject: Time-out for terminology question(s) Thanks for the positive comments regarding the drop-box thing. I did just reread appendix A and B in the 837 IG, however, and I want to be sure that I'm thinking about the same specific concepts and identifiers you folks are talking about. So here are a couple question areas: 1. The outer wrapper on the interchange (ISA-IEA) contains the ID of the sender and the receiver for the interchange. In the case of an interchange full of claims coming straight from a doctor or clinic, would this be the ID of the doctor or clinic? If the doctor uses a business agent to create the interchange, then the sender is the agent, right? 2. The ISA receiver, however, would seem to always be the final target... in the case of claim interchange, it would always be the PAYOR... right? The same payor identified on all the individual claims, right? 3. So how does each claim's loop 1000 fit into this? The IG says 1000 should contain the submitter and the receiver, but it seems to be duplicating other information in the ISA. Woudn't the submitter be the same for all claims within a single interchange... and also be the same entity who stuffed them into the ISA envelope? Thanks, Chris Christopher J. Feahr, OD http://visiondatastandard.org [EMAIL PROTECTED] Cell/Pager: 707-529-2268
Re: Whose name is it, anyway?
Bob: Maybe we're not at a crossroads if it's just a matter of having different definitions of things. Maybe that's why Rachel keeps on insisting we come to terms with, ...well, terms. Take proprietary vs non-proprietary. As in ID schemes (or domains). There's no allowance for the use of proprietary ISA sender and receiver IDs in the ISA - unless you mean the ZZ (mutually defined). Rachel gave us yesterday the list of valid sender and receiver qualifiers (domains) that may appear in a HIPAA compliant ISA: 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 All but the last, ZZ, are non-proprietary schemes, in that they have a well understood meaning and a single Registration Authority (RA). D-U-N-S 072930527 is unambiguously Novannet, LLC. Likewise, NAIC 54771 means Highmark. I'm sure someone could come up with their HIN if they're with a hospital or are a practitioner. Okay, maybe something like the DUNS+4 is semi-proprietary - in that the convention dictates the entity identified by the D-U-N-S in the first 9 digits assigns the last 4 digits. The HIN probably works the same way as DUNS+4. But I really don't see any wiggle room in most of these enumeration systems for any but the RA (e.g., HIBCC in the case of the HIN, Dun Bradstreet in the case of the D-U-N-S) to assign values - putting aside the possibility the owner can augment the values (e.g., DUNS+4 or the HIN). The only qualifier left is the ZZ (mutually defined) which could be construed as (fully) proprietary, and left to the whims of a payer or intermediary to assign for the provider to use. The HIPAA IG admittedly says you can use ZZ, and its use is therefore perfectly HIPAA compliant. But a proprietary ID numbering system is not standard (your ZZ value X is way different from another Clearinghouse's or Payer's ZZ value X). I'm at a loss to figure out how this group can build any recommendations for Trading Partner Identification based on its use. ZZ means whatever the beholder (the payer or the CH) says it means, and hence it is difficult to use as an interoperable standard for Identification. William J. Kammerer Novannet, LLC. +1 (614) 487-0320 - Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: WEDi/SNIP ID Routing [EMAIL PROTECTED] Sent: Wednesday, 23 January, 2002 02:31 PM Subject: Re: Whose name is it, anyway? William, Well, we are definitely at a crossroads. I strongly disagree with your assertion that use of ZZ and proprietary IDs could be construed as adversley impacting and therefore non-compliant. I understand fully your intent and where you are going. I disagree strongly with that direction and your insistance on separating the security aspects from the ISA issues. To me, that is doing the industry a disservice. You are moving to 'solve' a problem by ignoring another part of it. The supply side of health care is running quite differently than the 'insurance' side. VANs, drop boxes etc are a strong part of the supply side. Not of the insurance side. The insurance side is predominantly point to point. You may want to change things, but that takes a lot of time, and to do that you must address the full picture. And the security issues are an inherent part of that picture. Routing is NOT an issue today. We receive millions of claims per month from providers, billing services and clearinghouses. At last check, we have been receiving over 600,000 claims per month in X12 format. So do lots of others. The routing is there. Under HIPAA, it will still be there, and will be handled point to point. If you want to work on standardization of the ISA, I suggest that the ISSUE behind standardization is not routing, it is minimizing the number of IDs that must be maintained by the trading partners. And that issue can not be resolved without including the security issue. If you were to be highly successful and got the entire industry to move to a specific ID type for the ISA for each type of trading partner, you would STILL have a proliferation of IDs and passwords that were trading partner specific for access control and security. Someday, we may have good certificate solutions and encryption and Internet transport that will point to a total solution. Then a DNS or common directory will make security, routing and identification childsplay. People will wonder why this was such a probelm. It's just not here yet. In my opinion, the best bet is trying to move toward
