RE: [BULK] - RE: [BULK] - XML vs. EDI

[Kevin Day]

Title: Message

Bill,    My intent was not to address all the various issues raised on the subject but to merely answer the original request which was a simple explanation of what XML is and provide an objective opinion on how it could be viewed in relationship to X12.   Now that the simplicity aspect of my response is out, here are a few more details I sense you were looking to get out of it.   First, the dialect I chose in the example and you picked up on was indeed one example that one "could" be used. The attributes that were added were in fact optional. Generating them would in fact be an optional choice one would use. The actual product used to generate that in fact provides such an option. I could debate the advantages and disadvantages of carrying over the original X12 feed but that would be a lengthy conversation. I would agree that one aspect of the use of XML which has been skirted a bit and you somewhat touch on is the size of documents produced by XML. Even with the most simplistic forms there is an embedded overhead associated with it. I've seen an X12 feed represented in XML 10-20x the size in bytes compared to the original document. With the added human readability comes at cost. XML is certainly not the answer itself but it does provide a much lower cost of entry for the smaller players or providers as the case may be.   My concern on this stream of emails is that most of them view EDI, X12 in particular, and XML as being mutually exclusive which is clearly not the case and has been demonstrated by many payers and CHs I have worked with the past few years. By including a simple syntax translation (i.e. EDI2XML and XML2EDI) functionality while maintaining the semantics across the translation the larger players are now able to provide more cost effective means to communicate with their trading partners while maintaining the interfaces to their backend systems. By converting X12 to XML you are now able to render the HIPAA transactions in a variety of forms be it HTML through a web page, another dialect of XML, or even to a proprietary flat file format (yes, XSL is the main tool to perform this). On a side note, one of the main reason for the creation of XML was the ability of documents to be self describing which X!@ obvious is not. Applying Stylesheet is a means to provide en even more human readable form such as a pretty HTML page but should not be required to be deployed in order for someone to be able to interpret a document. The partial sample I shared is one extreme of XML. I don't believe anyone can deny that with almost no experience in the XML syntax you could read that document and understand what it contained. The meaning of each field and the relationship of one field (element) to another (e.g. it's parent).  These techniques continue to be employed by more and more "gorillas" to lower their cost with the automation (although not entirely) of their adjudication processes and reduce their paper feeds. If there were ever to come a day when the industry were to indeed standardize on a particular XML dialect the opportunity to directly connect even more providers to payers will become much more feasible. Although we may tend to think that the focus may indeed be the need to have the machines on two sides of a relationship communicate directly that is only one aspects of it. Inevitably human intervention is needed. Not only from the initial entry point into the process flow but at various points along the process such as exception handling, real time reporting, etc.. XML provides a much better form in which to give a business user a view into the data as it passes through the processes. As I state, passing the added meta-data along with the data itself does come at a cost and there are various ways to limit that cost. However; the benefits for the overall cost reduction in the industry in my opinion far outweighs the cost.   The mentioning of the existing applications that are found on everyone's desk which already support XML was to illustrate the the fact that the tools are already present and fairly inexpensive to use for the creation of XML. It doesn't take much time or effort to create a simple Word form that can generate an XML document such as a claim which could then be emailed with a response emailed back within hours. On the payer side supporting XML gives the potential to provide more web interfaces into their system. Yet, the issue of non standardized XML for Healthcare becomes the stumbling block. No one wants to invest in interfaces electronically with XML without a common standard since it will require costly alterations later when one is finely produced which leads us back to why X12 is the one electronic document protocol we have left to use. It contains a common syntax and semantic dialect.   My bottom line point is that both EDI (X12 is merely one form) and XML can and in all practical purposes should co-exist to both lower the cost of entry by the smaller players (e.g. office mgt software vendors) as well as allow the larger players (payers) to capitalize on interfaces to existing backend systems that took years and millions to design, develop, deploy and maintain. A drive to a common form of an XML standard would be a key part of bringing those of us that produce and consume the documents closer to allowing complete interoperability which in turn will lead to a reduction in the processing steps thus reducing cost. In the meantime, the need for such intermediaries to help with the communication across the various entities in the process flow is inevitable as they provide the needed function that thrives where standardization is limited be it in the form of document or transportation protocols. This doesn't mean XML can't be used now in healthcare processes. It's just need to be used wisely with forethought into migration to a standard whenever that becomes reality.    Kevin   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 The opinions expressed in this email are solely of the author and do not necessarily reflect those of Vitria Technology, Inc.      -----Original Message----- From: Bill Chessman [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 04, 2003 9:44 AM To: WEDI SNIP Transactions Workgroup List Subject: [BULK] - RE: [BULK] - XML vs. EDI 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 --- 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