Thanks, Jan! While this seems obvious, I've had payors react with disbelief and surprise when I make this assertion. But the other, perhaps more malignant, aspect of this is that providers don't seem to be upset either! A very small # of them are aware of the labor-intensive aspect of this and are "doing the math", but most just seem to regard DDE as a small but positive step in the direction of automation. In net-$, however, it can be a step backwards... at best it's probably a lateral move. DDE systems will disappear overnight when doctors (and hospitals) stop using them and lean on their software vendors to provide real EDI solutions.
This is one more reason to think about creating a national, provider-oriented SDO (for all non-retail-pharmacy providers). I can hear the collective groan, but wait a second! This would not REQUIRE any attendance by members of the payor or CH industry. Representatives from a monolithic provider-SDO could, however, attend all the current DSMO meetings in sufficient numbers to populate any workgroup that even remotely impacted providers. The vision industry has finally (this week, actually) acknowledged the need for an internal industry organizational structure for modeling/articulating our special data requirements for eyewear claims... and THAT organization (we still don't know what to call it) will be able to speak with a single voice to HL7 and X12 about HIPAA messaging standards...as well as to our manufacturers' association about related supply-chain transaction standards. The more I think about this, however, the more I believe that a parallel effort should be underway to represent ALL doctors, hospitals, labs, and DME providers. Virtually all types of providers have a need to share information amongst themselves and to aggregate information about TREATMENT across the healthcare industry. So while we would all benefit from standard medical record structures, etc., I don't think we want 15 different provider groups "standardizing" medical record formats individually. I'm not even sure which existing SDOs would want to tackle national EMR standardization. Does anyone know who might be working on EMR standards now? Something else to think about... (like we don't have enough!) -Chris At 10:28 AM 5/10/02 -0600, Jan Root wrote: >All >I would second what Chris said. From the provider's perspective, DDE >systems are >not a very good solution - better than paper yes, but a lot of work. It's >sort >of the electronic equivalent of having to deal with a proprietary form for >each >payer, at least from the "I gotta handle each payer individually" perspective. >Provider like a 'one-stop'shopping' solution to submitting claims, >eligibility, >etc and receiving RAs and other response transactions. > >Jan Root > > >"Christopher J. Feahr, OD" wrote: > > > Alan, > > Thank you for your comment. I think you are absolutely correct about > > provider DDE systems (and everything else) eventually morphing into an XML > > version of "EDI". Given the huge pent-up desire to implement XML and the > > interesting work that OASIS, X12, and others are doing today to create > > hybrids of XML and EDI message/transport structures... I think its very > > possible that most small providers will never actually see a classic EDI > > message inside their offices. So, while I did suggest we "phase them all > > out"... I didn't REALLY think that anyone would try to kill DDE with a > > law. By the time such a law became enforceable, we'd be ready to migrate > > from XML to the "next big thing"! > > > > My point, however, is that we should not make the mistake of thinking that > > DDE systems are very useful to the provider... THEY ARE LABOR-INTENSIVE, > > MANUAL SYSTEMS. The "electronic" advantages of DDE are ALL on the payor > > end. In the doctor's offices, they still have $20/hr. employees clicking > > around on websites with browsers and 33K dialup connections. Doctors' idea > > of "automation" is to get a DSL line for the office! HIPAA done entirely > > through a DDE interface doesn't improve doctors' live a bit (in my > > opinion), but it still allows payors to reduce the sizes of their call > > centers and eliminate many data-entry positions. > > > > Best regards, > > -Chris > > > > At 04:37 PM 5/8/02 -0400, Hirth, Alan wrote: > > > > > >I don't support the idea of phasing out DDE. Forcing providers off of a > > >browser/web based eligibility inquiry, claim status inquiry, and/or claim > > >entry system and onto pure EDI is counter productive. Encouraging DDE > as a > > >supplement to EDI and working to merge the two by developing HIPAA XML > seems > > >like a better long term strategy. > > > > > >-----Original Message----- > > >From: Christopher J. Feahr, OD > > >To: [EMAIL PROTECTED]; [EMAIL PROTECTED] > > >Sent: 5/8/02 3:37 PM > > >Subject: RE: Data Downloads from DDE Applications > > > > > >Rachel, > > >I would agree with your interpretation of the conventional usage of > > >terms > > >like "print screen" and "download"... but I do not see clear support in > > >the > > >law for your definitions. In order to display data on a provider's DDE > > >screen, I would argue that the payor is, in fact, "downloading" or > > >"transferring" data to the provider's system in a non-standard > > >format. There seems to be a need to better define not only the details > > >of > > >this special type of transfer, but whether there are any restrictions on > > > > > >what the provider can legally do with the data after it is > > >transferred... > > >whether it even HAS to wind up on a "screen" or display device... > > >whether > > >data could be pushed out to a provider's screen under this exception > > >without the provider requesting it immediately beforehand, etc. > > > > > >My suggestion (which, of course, would be pretty difficult to implement) > > >is > > >that we tighten up the definition of "DDE" systems and then permit them > > >to > > >be used for another 2 or 3 year transition period... and then phase them > > > > > >all out! > > > > > >regards, > > >Chris > > > > > >At 04:04 PM 5/6/02 -0500, Rachel Foerster wrote: > > > >Kris, > > > > > > > >The core difference between a print screen and a file download is just > > > >that -- when someone prints a screen no data is being downloaded to the > > > > > > >local system for additional processing -- the screen (display) is > > >intended > > > >for a human-to-computer interface. On the other hand, a file download > > >is > > > >not intended for a human-to-computer interface, but rather, is intended > > > > > > >for automated processing or a computer-to-computer interface. Just > > >because > > > >there may be human intervention with a downloaded file, the data in the > > > > > > >file is intended to be input into another application and not viewable > > >"as > > > >is" by a human. > > > > > > > >Therefore, if a file of data is being downloaded, regardless of the > > > >transport mode, e.g., HTTP, ftp, or even attached to an email, and the > > > >data constitutes one of the covered HIPAA transactions, after either > > > >10/16/02 or 10/16/03, the format of the data and the data content must > > > >comply with the appropriate HIPAA implementation guide. > > > > > > > >Rachel > > > >-----Original Message----- > > > >From: Owens, Kris [mailto:[EMAIL PROTECTED]] > > > >Sent: Monday, May 06, 2002 9:06 AM > > > >To: '[EMAIL PROTECTED]' > > > >Cc: Goulart, Cesar; '[EMAIL PROTECTED]' > > > >Subject: RE: Data Downloads from DDE Applications > > > > > > > >Rachel, > > > > > > > >Thanks for the response, although it is not what I had hoped to hear. > > > > > > > >Another thought (yes, I am still trying to justify giving this ability > > >to > > > >the providers) how would this download be different (in concept) from > > >the > > > >provider using a print screen option in their operating system? > > > > > > > >Kris Owens > > > >923-8108 > > > > > > > >"There is no meaning in isolation" > > > > > > > >-----Original Message----- > > > >From: Rachel Foerster [mailto:[EMAIL PROTECTED]] > > > >Sent: Saturday, May 04, 2002 1:15 PM > > > >To: [EMAIL PROTECTED] > > > >Subject: RE: Data Downloads from DDE Applications > > > > > > > >Kris, > > > > > > > >My understanding of the DDE exception plus the HHS FAQs on the subject, > > > > > > >lead me to conclude that the download of the eligibility information > > >would > > > >be a covered transaction under the electronic transaction final rule, > > >and > > > >thus, must conform to the 271 specifications. > > > > > > > >Rachel Foerster > > > > > > > >-----Original Message----- > > > >From: Owens, Kris [mailto:[EMAIL PROTECTED]] > > > >Sent: Friday, May 03, 2002 4:12 PM > > > >To: [EMAIL PROTECTED] > > > >Cc: Goulart, Cesar > > > >Subject: Data Downloads from DDE Applications > > > > > > > >We have a web application for our healthplan that supplies eligibility > > >and > > > >claims status information to providers. Once a provider has displayed > > >the > > > >information, they have an option to "download" the information to their > > > > > > >PC. My question - should we consider the download to be a covered > > > >transaction? > > > >I find the following in the regulations: > > > > > > > >160.103 Transaction means the exchange of information between two > > >parties > > > >to carry out financial or administrative activities related to health > > >care. > > > >162.923 (a) General rule. Except as otherwise provided in this part, if > > >a > > > >covered entity conducts with another covered entity (or within the same > > > > > > >covered entity), using electronic media, a transaction of which the > > > >Secretary has adopted a standard under this part, the covered entity > > >must > > > >conduct the transaction as a standard transaction. > > > >(b) Exception for Direct data entry transactions. A health care > > >provider > > > >electing to use direct data entry offered by a health plan to conduct a > > > > > > >transaction for which a standard has been adopted under this part must > > >use > > > >the applicable data content and data condition requirements of the > > > >standard when conducting the transaction. The health care provider is > > >not > > > >required to use the format requirements of the standard. > > > >162.1201 Eligibility for a health plan transaction (a) An inquiry from > > >a > > > >health care provider to a health plan, or from one health plan to > > >another > > > >health plan to obtain...(1) Eligibility to receive health care under > > >the > > > >health plan. (2) Coverage of health care under the health plan. (3) > > > >Benefits associated with the benefit plan. (b) A response from a > > >health > > > >plan to a health care provider's (or another health plan's ) inquiry > > > >described in the paragraph(a) of this section. > > > >162.1402 Health care claims status transaction. (a) An inquiry to > > > >determine the status of a health care claim. (b) A response about the > > > >status of a health care claim. > > > >OK, so I read all this and it would seem that the downloads are to > > >carry > > > >out administrative activities, and they are eligibility responses, or > > > >claims status responses. My only hope is that the web application has > > > >already done the request and response and that this is somehow after > > >the > > > >fact, and therefore not covered... or perhaps the fact that this is > > >from a > > > >DDE application gets us by the format requirements. If these are in > > > >fact a covered transaction they become useless because the providers > > >that > > > >are utilizing these are doing so because they have no technical > > >facility > > > >to handle an X-12 format. > > > >Any thoughts? > > > > > > > > > > > > > > > >Kris Owens > > > >Senior IS Project Manager - HIPAA Project > > > >Presbyterian Healthcare Services > > > >Albuquerque, NM > > > >505.923.8108 > > > >[EMAIL PROTECTED] > > > > > > > >"There is no meaning in isolation" > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >--- PRESBYTERIAN HEALTHCARE SERVICES DISCLAIMER --- > > > > > > > >This message originates from Presbyterian Healthcare Services or one of > > > > > > >its affiliated organizations. It contains information, which may be > > > >confidential or privileged, and is intended only for the individual or > > > >entity named above. It is prohibited for anyone else to disclose, copy, > > > > > > >distribute or use the contents of this message. All personal messages > > > >express views solely of the sender, which are not to be attributed to > > > >Presbyterian Healthcare Services or any of its affiliated > > >organizations, > > > >and may not be distributed without this disclaimer. If you received > > >this > > > >message in error, please notify us immediately at [EMAIL PROTECTED] > > > > > > > > > > > > > > > >--- PRESBYTERIAN HEALTHCARE SERVICES DISCLAIMER --- > > > > > > > >This message originates from Presbyterian Healthcare Services or one of > > > > > > >its affiliated organizations. It contains information, which may be > > > >confidential or privileged, and is intended only for the individual or > > > >entity named above. It is prohibited for anyone else to disclose, copy, > > > > > > >distribute or use the contents of this message. All personal messages > > > >express views solely of the sender, which are not to be attributed to > > > >Presbyterian Healthcare Services or any of its affiliated > > >organizations, > > > >and may not be distributed without this disclaimer. If you received > > >this > > > >message in error, please notify us immediately at [EMAIL PROTECTED] > > > > > >Christopher J. Feahr, OD > > >http://visiondatastandard.org > > >[EMAIL PROTECTED] > > >Cell/Pager: 707-529-2268 > > > > > > > > > > > >The contents of this e-mail are intended for the named addressee only. It > > >contains information that may be confidential. Unless you are the named > > >addressee or an authorized designee, you may not copy or use it, or > disclose > > >it to anyone else. If you received it in error please notify us > immediately > > >and then destroy it. > > > > Christopher J. Feahr, OD > > http://visiondatastandard.org > > [EMAIL PROTECTED] > > Cell/Pager: 707-529-2268 Christopher J. Feahr, OD http://visiondatastandard.org [EMAIL PROTECTED] Cell/Pager: 707-529-2268
