RE: [BULK] - XML vs. EDI

[Bill Chessman]

Title: Message

There are some interesting points here, but I'd like to focus in on a couple that I think get overlooked in all the hype.  Kevin, in his excellent answer points out that he has, "...a simple example of what a small X12 document could look like in one example XML dialect..."  My particular pinpoint focus is on the word "could".  The situation today is that there is yet no "official standard" DTD or schema from X12 (though I understand that work continues in that direction).  This example is a very valid one though one might wonder about the redundancy of transmitting an element's description every time you transmit the element (some elements such as "reference number" are sufficiently generic that they are used in many, many places)...but I digress.  Back to "could":  We've also seen from Joe Barten an entirely different approach to the XML from X12 which, amazingly, provides one-to-one mapping (as does Kevin's) but also preserves the X12 syntax within the XML syntax.   Frankly I don't endorse either of these approaches for different reasons.  At the same time, this is not to say that XML is bad, evil, invalid, or otherwise objectionable.  As Rachel Foerster points out, XML certainly can be more human-readable and and more flexible (that flexibility really is a double-edged sword).   Oh, and there was a second comment in Kevin's note that I wanted to touch on:  "Support for XML as mentioned in several of these threads is imbedded in much of the software you currently use such as MS Explorer, Outlook or Word."  I'd just offer a caveat here:  This doesn't guarantee or imply that any given application that "does XML" would have any idea what to do with either of the examples (or any other XML, for that matter).  Sure, they can read it they can parse it, they can display it in a pretty, hierarchical format (I've done this with various browsers including Internet Explorer, Netscape and Mozilla with varying degrees of success), but if the goal is to get the data out of the XML document and into a database, as Rachel pointed out, both EDI and XML "still require that the very time consuming, laborious mapping and syncing of semantics be done by human beings."   One other aspect I've seen discussed with regard to XML:  Human-readability.  XML does not guarantee this.  XML is more or less, just the framework, the syntax, the rules on what data goes where (and to a limited degree, what format it takes).  It is up to the designer of the tags and the data hierarchical relationships to ensure that humans can read it...if that is an important goal.  My question is: If our focus in on the transfer of data from computer system A to computer system B without either having particular knowledge about the other and without human intervention (which is basically the goal of EDI), how important is human readability in the underlying XML.  If human readability is truly desireable, and I'm sure in certain circumstances it is, then the coupling of style-sheets with XML can provide much better readability than raw XML does (again, good design goes a long way...).   But enough philosophy.  8-)   Best regards, Bill Chessman Inovis(tm), Inc. -----Original Message----- From: Kevin Day [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 03, 2003 4:58 PM To: WEDI SNIP Transactions Workgroup List Subject: RE: [BULK] - XML vs. EDI Ralph,    A simple way to think of it is this. EDI and X12N in particular should be consider a form of a language. Just like with any language you need syntax and rules that govern the syntax. Syntax rules allow you to define structure of the language so there is consistent interpretation of the structure. In X12 the syntax (aka dialect) consist of terms such as Segment, Element, Mandatory, Optional, Values, Loops. XML is no different. It too has a syntax which governs it. In fact, XML is in essence a language for defining languages or in other words a syntax for defining other syntax. It stands for eXtensible Markup Language. It looks much like HTML in that it has tags. For example, <ST_0010>. It has the ability for you or anyone else to define your own syntax be defining what are known as DTDs or Schemas that define structures much like the X12 IGs and sample define the structures of X12 documents. Support for XML as mentioned in several of these threads is imbedded in much of the software you currently use such as MS Explorer, Outlook or Word. Unlike HTML where the tags were used to define the use of the data XML gives you the ability to define your own tag (aka element) names. Which means you can define your own ML or Markup Language for your own documents.   One thing that ties both syntax together at least should tie them together is common meaning or semantics. Just like when you have two people talking about the weather one speaking English and the other speaking French you need a common set of terms and their meanings to have a meaningful conversation. Of course a translator is needed to convert back and forth from one dialect to the other. And just like the pocket translator I carry when I head to Europe there are translators that help convert from one dialect to the other such as between X12 and XML. The tricky part is what form of XML? Since XML in and of itself is nothing but a language which you can use to create you own dialect you need to know what dialect or standard of XML you want to use. This where much of the new battles are being fought in this industry and every other one out there. That is the race to define a dialect in XML for Healthcare. There are several efforts going on and I participate in several of them along with other industries and I see the same fights across them The syntax itself is hard enough but you will find the same fights industries had over when defining the X12 semantics you will find in the process of defining XML dialects. Although the syntax between X12 and XML are different their meaning are not. Here is a simple example of what a small X12 document could look like in one example XML dialect but have the exact same meaning :   ISA*00*          *00*          *ZZ*133052274      *ZZ*642460001      *010816*123 1*U*00401*000000001*0*T*^~GS*HC*133052274*642460001*20010816*1231*000000001*X*00 4010X096~ST*837*000000001~BHT*0019*00*1* ........       <?xml version="1.0" encoding="UTF-8"?> <Interchange>     <ISA desc="Interchange Control Header">         <ISA01 desc="Authorization Information Qualifier">00</ISA01>         <ISA02 desc="Authorization Information">          </ISA02>         <ISA03 desc="Security Information Qualifier">00</ISA03>         <ISA04 desc="Security Information">          </ISA04>         <ISA05 desc="Interchange ID Qualifier">ZZ</ISA05>         <ISA06 desc="Interchange Sender ID">133052274      </ISA06>         <ISA07 desc="Interchange ID Qualifier">ZZ</ISA07>         <ISA08 desc="Interchange Receiver ID">642460001      </ISA08>         <ISA09 desc="Interchange Date">010816</ISA09>         <ISA10 desc="Interchange Time">1231</ISA10>         <ISA11 desc="Interchange Control Standards Identifier">U</ISA11>         <ISA12 desc="Interchange Control Version Number">00401</ISA12>         <ISA13 desc="Interchange Control Number">000000001</ISA13>         <ISA14 desc="Acknowledgment Requested">0</ISA14>         <ISA15 desc="Usage Indicator">T</ISA15>         <ISA16 desc="Component Element Separator">^</ISA16>     </ISA>     <Division>         <GS desc="Functional Group Header">             <GS01 desc="Functional Identifier Code">HC</GS01>             <GS02 desc="Application Sender&apos;s Code">133052274</GS02>             <GS03 desc="Application Receiver&apos;s Code">642460001</GS03>             <GS04 desc="Date">20010816</GS04>             <GS05 desc="Time">1231</GS05>             <GS06 desc="Group Control Number">000000001</GS06>             <GS07 desc="Responsible Agency Code">X</GS07>             <GS08 desc="Version / Release / Industry Identifier Code">004010X096</GS08>         </GS>         <Health_Care_Claim__Institutional>             <ST_0010 desc="Transaction Set Header">                 <ST01 desc="Transaction Set Identifier Code" valueDesc="Health Care Claim">837</ST01>                 <ST02 desc="Transaction Set Control Number">000000001</ST02>             </ST_0010>             <BHT_0020 desc="Beginning of Hierarchical Transaction">                 <BHT01 desc="Hierarchical Structure Code" valueDesc="Information Source, Subscriber, Dependent">0019</BHT01>                 <BHT02 desc="Transaction Set Purpose Code" valueDesc="Original">00</BHT02>                 <BHT03 desc="Originator Application Transaction Identifier">1</BHT03>                 <BHT04 desc="Transaction Set Creation Date">20010816</BHT04>                 <BHT05 desc="Transaction Set Creation Time">1231</BHT05>                 <BHT06 desc="Claim or Encounter Identifier" valueDesc="Chargeable">CH</BHT06>             </BHT_0020>   NOTE : The preceding partial XML document is one example of a dialect that could be used to represent the same data  in an X12 document in XML syntax. the "desc" is called an ATTRIBUTE and something the author of this dialect chose to add a description to each of the elements. The author also chose to create a dialect that mirrors the X12 syntax as close as possible for the purposes of keeping the transition from one to the other as simple as possible.   You can find more about XML in general at http://www.w3.org/XML/ as well as other industry specific websites that are pursuing their own standard syntax based on it.     Kevin Day - Sr. Program Manager Vitria Technology, Inc. www.vitria.com 945 Stewart Rd. Sunnyvale, CA 94086 TEL : 408.212.2529 CELL : 408.368.7783 -----Original Message----- From: Mazza, Ralph [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 03, 2003 12:20 PM To: WEDI SNIP Transactions Workgroup List Subject: [BULK] - XML vs. EDI Can anyone point to a dumbed-down explanation of what XML is and what distinguishes it from EDI?  It's not that I have nothing else to do, but despite my ignorance of technical matters, I would like to gain a rudimentary understanding of what this EDI vs.. XML debate is all about.      -----Original Message----- From: Bill Chessman [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 03, 2003 2:01 PM To: WEDI SNIP Transactions Workgroup List Subject: RE: Transition paper Of course, this begs the question:  If XML is so terrific, why on earth must they "shove" the X12 transactions into it?  Seems to me this is yet another incarnation of the EDI vs. XML debate.  Don't think anyone's been swayed in either direction in a while...  Don't see any new, compelling arguments for either one...  8-\   Best regards, Bill Chessman Inovis(tm), Inc. -----Original Message----- From: Rachel Foerster [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 03, 2003 10:12 AM To: WEDI SNIP Transactions Workgroup List Subject: RE: Transition paper David, if Microsoft is so committed to traditional EDI and the use of X12 and/or EDIFACT, then tell why on earth Bill Gates has bet the entire fortune and future of Microsft on XML and its .NET platform. Even Biztalk is XML centric and it does a real hokey schema stuff to shove the HIPAA X12 transactions into it.   Rachel -----Original Message----- From: David Frenkel [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 03, 2003 10:39 AM To: WEDI SNIP Transactions Workgroup List Subject: RE: Transition paper Rachel, You are making some broad generalizations.  It would be useful to at least cite some published metrics to support your conclusions.  I can mention that one of the titans of US industry, Microsoft, continues to expand its EDI program on Microsoft OS platforms.  One of Microsoft's recent largest EDI rollouts was for their Xbox product to get on the shelves of another industry titan Wal-Mart (which has pharmacies covered under HIPAA).  I can site numerous other companies that are expanding their EDI programs both on mainframe and non-mainframe.  I would disagree about your concept of legacy EDI only on mainframes.  There are many definitions of mainframes but the mainstream concept of a mainframe computer is an IBM 30xx and its variants although there are more inclusive definitions.   EDI is workable it is the older 'brittle' adjudication systems I think you are referring to that are causing the real problems.   Regards,   David Frenkel Business Development GEFEG USA Global Leader in Ecommerce Tools www.gefeg.com 612-237-1966 -----Original Message----- From: Rachel Foerster [mailto:[EMAIL PROTECTED]] Sent: Tuesday, June 03, 2003 12:38 AM To: WEDI SNIP Transactions Workgroup List Subject: RE: Transition paper   Miriam, with all due respect, while I agree that for many industries and large companies that have invested in a traditional EDI infrastructure are not walking away from it....they are NOT continuing to invest more dollars and resources into traditional EDI. Traditional EDI is based on legacy mainframe batch processing concepts, is much too abstract and much too brittle to support the 21st century's needs for global interoperable electronic business messaging.   For the life of me I don't see why healthcare should implement something that other industries did 20-30 years ago because it was the available solution THEN simply because it worked BACK THEN. It's not the foundation on which to build for the 21st century and for healthcare to continue down this path, it will be spending tens of billions of dollars to implement a brittle, unworkable legacy capability while the rest of the world has moved on.   Rachel Rachel Foerster Chief Executive Officer Rachel Foerster & Associates, Ltd. Ideas - Promotion - Innovation Voice: 847-872-8070 email: [EMAIL PROTECTED] http://www.rfa-edi.com -----Original Message----- From: Miriam Paramore [mailto:[EMAIL PROTECTED] Sent: Monday, June 02, 2003 2:47 PM To: WEDI SNIP Transactions Workgroup List Subject: RE: Transition paper Dr. Feahr, Peter et al,   With all due respect, my 2 cents.   EDI is still the backbone of most of the sexy e-commerce that is running other industries -- manufacturing, retail, etc.  Even those that are implementing cool XML and web stuff still have an EDI backbone under the covers.    Healthcare needs the backbone that has proven successful in other industries and that is why I don't think HIPAA is barking up the wrong tree.  To try and create consensus in a non-X12 standard -- after it took a decade to get it for X12 -- would simply have us asking the same questions a decade from now about what is wrong with that standard. Best Regards, Miriam J. Paramore (Co-Founder and President of HAWK) President & CEO PCI: e-commerce for healthcare 9001 Shelbyville Road iTRC Building Louisville, KY 40222 502-429-8555 www.hipaasurvival.com =========================================== This email contains confidential information intended only for the named addressee(s). Any use, distribution, copying or disclosure by any other person is strictly prohibited. -----Original Message----- From: Christopher Feahr [mailto:[EMAIL PROTECTED] Sent: Monday, June 02, 2003 1:41 PM To: WEDI SNIP Transactions Workgroup List Subject: Re: Transition paper (Please forgive the cross-posting to "business issues", but I think it belongs there too)   Dear Peter, Thank you again for this thoughtful and evenly balanced statement of the problem and proposed solutions.  I would offer a few comments, however, on your new 6.18 section that answer's Rachel's question "Is legal relief of any type just treating symptoms and not the illness?"   First, we need to keep in mind that we have 2 problems to solve: the deadline and the original cost/inefficiency problem that TCS was intended to mitigate.  I agree that the deadline problem is tricky... but it's also completely artificial.  Give me a few hours with the Federal register and a pail of White-Out and I can make that problem disappear!  The administration can stick to its guns and derail the healthcare industry right before an election year... or it can maintain the status quo while we ALL (providers included) take a deep breath and a second look at the ORIGINAL problems TCS was intended to fix.  In my view, this is a no-brainer for President Bush's Administration.   "Managed Legal Relief" is by far the most detailed and intelligent proposal I have seen for averting the Certain Disaster of obeying the law and/or the Tragedy of entirely calling off our noble effort to remove cost/error from healthcare.   At the same time, however, we MUST address the questions that Rachel and I and many others are raising about the wisdom of using EDI as the standard in an industry as important and as fragmented as healthcare.  There are only two positions that I can imagine us adopting with respect to the present Rule and EDI:   1. EDI is a good and workable concept for our industry... today... and people just need to get more serious about implementation.  OR   2. EDI is physically incapable of removing net cost or improving net efficiency in healthcare... that both it and the regulatory process that is presently driving it are, in fact, ADDING cost/complexity to an industry already overburdened with its core mission of delivering care.    Does anyone in healthcare anticipate true ROI from the existing Transaction Rule... even for the billions we have already invested in EDI?  What about ROI for EDI-development dollars spent over the next couple years?  These questions must be answered WHILE we struggle with the self-inflicted problem of the deadline.  Until a few weeks ago, it was considered "in very bad taste" to openly criticize the federal government's plan or suggest it will not accomplish its stated objective.  If I'm really the only guy in the country who thinks EDI is barking up the wrong tree and that pouring additional development dollars into it would be a BAD idea in Q4 of 2003... then I guess I'll have to shut up and go back to being an eye doctor.  If you think I'm on the right track, however... but simply believe we'd never be able to execute such a dramatic course change in such a short time... then I ask you to remember two concepts:  TRAIN WRECK and ELECTION YEAR.  There is plenty of motivation here for a dramatic course change!   I think it would be very helpful to step WAY back from HIPAA for a moment and ask ourselves, "What is the most sensible course of action for ALL industry stakeholders and for our Patients... from this moment forward?"   Best regards, -Chris   Christopher J. Feahr, O.D. Optiserv Consulting (Vision Industry) Office: (707) 579-4984 Cell: (707) 529-2268 http://Optiserv.com http://VisionDataStandard.org ----- Original Message ----- From: [EMAIL PROTECTED] To: WEDI SNIP Transactions Workgroup List Sent: Sunday, June 01, 2003 8:04 PM Subject: Re: Transition paper   I would like to thank those who have sent comments.  Three so far have been to the listserv; so I would like to answer those in the listserv format. A.  To David Frenkel, who asked if I had tested the conclusions of the paper in Washington (see below).  David, thanks for your comments.  I always find your emails must reading.  My expectation is that the concept of administrating the implementation using status information linked to legal relief may not be intuitively attractive to HHS.  I thought it needed to be said anyway.  Although it is a small amount of work now, it stands the better chance of controlling the delay such that we would not face it anew, say, a year from now.  I would hope the give it close examination.  Saying that, I have very high regard for HHS and CMS administration and will contentedly go along with the outcome.  The paper also has other value, including:   -  description of the risk we are facing   -  description of the causes of the risk, c.f. 6.7   -  discussion of, as WEDI asked, what it means to be compliant; c.f 1.3, 5.1.2, 5.1.4, 6.1, and 6.2   -  description of the criteria for waiver of penalty; c.f. 2.3-2.6. B.  To Susan Hollabaugh, who asked, since we are proposing to gather information anyway, why not get the underlying or internal status information that in most cases is driving the pace of implementation.  Thanks, Susan, for bringing up a great point.  I have added a new paragraph 6.17 to the paper should it ever go out with another new version.  The paragraph is reprinted below. C.  To Rachel Forster who complimented me by including a reference to the paper along with the WEDI and AHA letters and with Kepa's 3rd essay on market forces.  Rachel, I agree heartily with the potential for new technology but am not so sure about its relevance to today's problem.   I have added a new paragraph, 6.18, quoted below, on this and some related subjects. Again, thanks you all for even reading the paper.  It is an entertaining subject. 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] ------------------------------------------------------------------------------------------- New paragraphs added to the paper: 6.17 Why just gather the status between trading partners? This paper only proposes to gather the status between trading partners.  It does not propose to gather information on internal projects of a covered entity even though internal information might be highly indicative of eventual progress.  But internal information might be unnecessarily intrusive, more subjective, and gathering it would definitely burden the industry.  Instead, this paper proposes to index only the more objectively defined status on EDI exchange.  It is simpler, oriented to results rather than project steps, and does not burden the industry. 6.18 Is legal relief of any type just treating symptoms and not the illness? One line of discussion is that this paper, the WEDI letter, AFEHCT and AHA testimony, Drs. Braithwaite's and Fusile's report, and Dr. Zubeldia's essay on market forces represent Band-Aids, that they do not address the underlying problem.  The underlying problem is variously suggested to be (1) that government fiat is unworkable, (2) it places undue or inequitable demand on smaller entities, (3) it ignores the financial plight of providers, (4) it is high distraction from a Medicare/Medicaid funding crisis, and (5) it is too complex, cumbersome, and costly to implement.  It is frequently suggested that EDI technology is old and problems would be much less if more modern technology were used instead. I view all these points as interesting topics for discussion.  They are more than philosophic discourse, but they do not address the present problem of October 16th; so they completely miss the point.  Since there is no way the industry can meet the deadline, the government has only two possible actions:  (1) abandon the effort, or (2) give relief from the deadline.  Abandonment is defeatist, ignores the excellent gains and potential good that will come of the present effort, and would cause its own heavy costs and dislocation.  It is also politically infeasible.  So the only viable course is to provide legal relief.  The central thesis of this paper is that the relief should be linked with status information to enable effective administration. 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] --------------------------------------------------------------- Peter, Have you tested the political waters in Washington with your conclusions?  There seems to be bigger distractions in Congress in regards to Medicare drug benefits and diminishing Medicare reimbursements.  On top of all this next year is a presidential election.  It is already well known that most hospitals in the US are already having financial problems and there appears to be little effort to alleviate this regardless of the HIPAA issues. Regards, David Frenkel Business Development GEFEG USA Global Leader in Ecommerce Tools www.gefeg.com 612-237-1966 ----------------- Forwarded Message: Subj: RE: Transition Paper Date: 5/30/2003 9:16:27 PM Central Daylight Time From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent from the Internet (Details) Peter, I found your paper full of great ideas and  I am circulating it within my own organization. I do have one concern regarding the gathering of status information. I work for a provider organization and we do use a clearinghouse but our clearinghouse only knows what our status is with them. However, there are many steps that lead up to the point of even submitting claims to our clearinghouse to test. 1)status of our PMS HIPAA upgrade, 2) our competence level with the IGs 3)status of our payer surveys and the collection and review of Companion Guides 4)data gathering related to the requirements laid out in the companion guides 5) completion of a gap analysis and all the other countless things I have forgotten to mention. If our CH uploads information regarding our HIPAA status with them to the Data Gathering Website, it would not be a true reflection of where we (the provider) are in the implementation efforts. If we are trying to determine how ready the industry is then it seems to me we need to know this type of information as well. For example, we have done a Work Flow Inventory, a Gap Analysis, modified many of our Patient Registration Forms to collect new date, developed a comprehensive training program to train staff to collect the new data, developed materials to explain to patients why we are asking all these new questions, begun testing with a third party organization (prior to sending to our CH), etc... We are in a very different place than many of the other providers that submit to the same CH that we use, but the CH does not record or store this type of detail. If we are going to take the time to gather industry wide detail on where we are, don't we need to know this type of information? Would the Clearinghouses be expected to gather this type of information about their providers? Susan -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Thursday, May 29, 2003 1:44 PM To: WEDI SNIP Transactions Workgroup List Subject: Transiion Paper Attached is an updated copy of the Transition paper I presented at the WEDI conference last week.  This builds on WEDI positions, but it does not in any way represent anyone's opinion by my own, errors and all.  If it is useful to you, you may freely distribute it.  Besides its recommendations, it may offer helpful description of the transition problem and business strategies to deal with it.  It also addresses the contest between technical perfection and general conduct of business, the latter prevailing to my thinking. 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] --- The WEDI SNIP listserv to which you are subscribed is not moderated. The 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/. These listservs should not be used for commercial marketing purposes or discussion of specific vendor products and services. They also are not intended to be used as a forum for personal disagreements or unprofessional communication at any time. You are currently subscribed to wedi-transactions as: [EMAIL PROTECTED] To unsubscribe from this list, go to the Subscribe/Unsubscribe form at http://subscribe.wedi.org or send a blank email to [EMAIL PROTECTED] If you need to unsubscribe but your current email address is not the same as the address subscribed to the list, please use the Subscribe/Unsubscribe form at http://subscribe.wedi.org --- The WEDI SNIP listserv to which you are subscribed is not moderated. The 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/. These listservs should not be used for commercial marketing purposes or discussion of specific vendor products and services. They also are not intended to be used as a forum for personal disagreements or unprofessional communication at any time. You are currently subscribed to wedi-transactions as: [EMAIL PROTECTED] To unsubscribe from this list, go to the Subscribe/Unsubscribe form at http://subscribe.wedi.org or send a blank email to [EMAIL PROTECTED] If you need to unsubscribe but your current email address is not the same as the address subscribed to the list, please use the Subscribe/Unsubscribe form at http://subscribe.wedi.org --- The WEDI SNIP listserv to which you are subscribed is not moderated. The 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/. These listservs should not be used for commercial marketing purposes or discussion of specific vendor products and services. They also are not intended to be used as a forum for personal disagreements or unprofessional communication at any time. You are currently subscribed to wedi-transactions as: [EMAIL PROTECTED] To unsubscribe from this list, go to the Subscribe/Unsubscribe form at http://subscribe.wedi.org or send a blank email to [EMAIL PROTECTED] If you need to unsubscribe but your current email address is not the same as the address subscribed to the list, please use the Subscribe/Unsubscribe form at http://subscribe.wedi.org --- The WEDI SNIP listserv to which you are subscribed is not moderated. The 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/. These listservs should not be used for commercial marketing purposes or discussion of specific vendor products and services. They also are not intended to be used as a forum for personal disagreements or unprofessional communication at any time. You are currently subscribed to wedi-transactions as: [EMAIL PROTECTED] To unsubscribe from this list, go to the Subscribe/Unsubscribe form at http://subscribe.wedi.org or send a blank email to [EMAIL PROTECTED] If you need to unsubscribe but your current email address is not the same as the address subscribed to the list, please use the Subscribe/Unsubscribe form at http://subscribe.wedi.org --- The WEDI SNIP listserv to which you are subscribed is not moderated. The 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/. These listservs should not be used for commercial marketing purposes or discussion of specific vendor products and services. They also are not intended to be used as a forum for personal disagreements or unprofessional communication at any time. You are currently subscribed to wedi-transactions as: [EMAIL PROTECTED] To unsubscribe from this list, go to the Subscribe/Unsubscribe form at http://subscribe.wedi.org or send a blank email to [EMAIL PROTECTED] If you need to unsubscribe but your current email address is not the same as the address subscribed to the list, please use the Subscribe/Unsubscribe form at http://subscribe.wedi.org --- The WEDI SNIP listserv to which you are subscribed is not moderated. The 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/. These listservs should not be used for commercial marketing purposes or discussion of specific vendor products and services. They also are not intended to be used as a forum for personal disagreements or unprofessional communication at any time. You are currently subscribed to wedi-transactions as: [EMAIL PROTECTED] To unsubscribe from this list, go to the Subscribe/Unsubscribe form at http://subscribe.wedi.org or send a blank email to [EMAIL PROTECTED] If you need to unsubscribe but your current email address is not the same as the address subscribed to the list, please use the Subscribe/Unsubscribe form at http://subscribe.wedi.org --- The WEDI SNIP listserv to which you are subscribed is not moderated. The 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/. These listservs should not be used for commercial marketing purposes or discussion of specific vendor products and services. They also are not intended to be used as a forum for personal disagreements or unprofessional communication at any time. You are currently subscribed to wedi-transactions as: [EMAIL PROTECTED] To unsubscribe from this list, go to the Subscribe/Unsubscribe form at http://subscribe.wedi.org or send a blank email to [EMAIL PROTECTED] If you need to unsubscribe but your current email address is not the same as the address subscribed to the list, please use the Subscribe/Unsubscribe form at http://subscribe.wedi.org --- The WEDI SNIP listserv to which you are subscribed is not moderated. The 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/. These listservs should not be used for commercial marketing purposes or discussion of specific vendor products and services. They also are not intended to be used as a forum for personal disagreements or unprofessional communication at any time. You are currently subscribed to wedi-transactions as: [EMAIL PROTECTED] To unsubscribe from this list, go to the Subscribe/Unsubscribe form at http://subscribe.wedi.org or send a blank email to [EMAIL PROTECTED] If you need to unsubscribe but your current email address is not the same as the address subscribed to the list, please use the Subscribe/Unsubscribe form at http://subscribe.wedi.org --- The WEDI SNIP listserv to which you are subscribed is not moderated. The 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/. These listservs should not be used for commercial marketing purposes or discussion of specific vendor products and services. They also are not intended to be used as a forum for personal disagreements or unprofessional communication at any time. You are currently subscribed to wedi-transactions as: [EMAIL PROTECTED] To unsubscribe from this list, go to the Subscribe/Unsubscribe form at http://subscribe.wedi.org or send a blank email to [EMAIL PROTECTED] If you need to unsubscribe but your current email address is not the same as the address subscribed to the list, please use the Subscribe/Unsubscribe form at http://subscribe.wedi.org --- The WEDI SNIP listserv to which you are subscribed is not moderated. The 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/. These listservs should not be used for commercial marketing purposes or discussion of specific vendor products and services. They also are not intended to be used as a forum for personal disagreements or unprofessional communication at any time. You are currently subscribed to wedi-transactions as: [EMAIL PROTECTED] To unsubscribe from this list, go to the Subscribe/Unsubscribe form at http://subscribe.wedi.org or send a blank email to [EMAIL PROTECTED] If you need to unsubscribe but your current email address is not the same as the address subscribed to the list, please use the Subscribe/Unsubscribe form at http://subscribe.wedi.org