Subj: Automated DDE Date: 5/7/2002 11:07:28 AM Central Daylight Time From: <A HREF="mailto:PETERBARRY";>PETERBARRY</A> To: <A HREF="mailto:[EMAIL PROTECTED]";>[EMAIL PROTECTED]</A>, <A HREF="mailto:[EMAIL PROTECTED]";>[EMAIL PROTECTED]</A> To: <A HREF="mailto:[EMAIL PROTECTED]";>[EMAIL PROTECTED]</A>, <A HREF="mailto:[EMAIL PROTECTED]";>[EMAIL PROTECTED]</A> CC: <A HREF="mailto:[EMAIL PROTECTED]";>[EMAIL PROTECTED]</A>
Dear Kris and Chris: Kris, your question is about the admissibility of connecting a DDE terminal at the provider's office to a computer application for recording information received from the payer, that is, screen scraping. Usually we hear of this in context also of screen painting. As a general term, we might call it "automated DDE", something like that. In the "Impact on DDE Services" paper we called it "computer simulated data entry" (paragraph 8.4). In some cases it is done as pure computer-to-computer; in other cases there is a person that participates if the submitted transaction gets an error. Probably the most significant use at present is for submission of Medicare claims, and some such simulation systems have been modified to submit other claims. Next Tuesday evening (exact time and place in the conference schedule) at the Denver WEDI meeting, there is a forum of DDE issues, specifically to address the question of "automated DDE" and the open FAQ regarding the impact of the equal treatment and no-incentive rules on DDE. The two are tied closely together in their effect. Bruce Horn wrote the following for the agenda: "DDE Forum Automated DDE -- Equal Treatment Provisions and No Incentive Provisions. How does the industry address the need for automated DDE and satisfy the requirements of HIPAA? Join us for an informal review of the current DDE provisions and the impact on automated DDE. We need your input to develop consensus agreement on how we are to address these important issues." On the one hand, I believe easing the prohibition against "automated DDE" while also allowing DDE to be more attractive in speed and data quality than standard transactions would very seriously and permanently undermine the standardization goals of HIPAA. On the other hand, I would not like to shut down existing operations, especially claims, before replacement capabilities are in place. It may be a difficult decision Should be spirited and interesting. Try to attend the forum. 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] . -------------------------- In a message dated 5/4/2002 1:39:03 PM Central Daylight Time, [EMAIL PROTECTED] writes: > Subj: Re: Data Downloads from DDE Applications > Date: 5/4/2002 1:39:03 PM Central Daylight Time > From: [EMAIL PROTECTED] (Christopher J. Feahr, OD) > To: [EMAIL PROTECTED] (Owens, Kris), [EMAIL PROTECTED] > CC: [EMAIL PROTECTED] (Goulart, Cesar), [EMAIL PROTECTED] > > Kris, > I've copied a couple sections from Peter Barry's white paper below, but > they do not seem to shed any light on your question. There seems to be > an assumption that data returned from payor to provider in a DDE scenario > is invariably displayed on a monitor, but I don't know why that data could > not be legally captured some other way by the provider's system. The rules > do not seem to even discuss the return path. Clearly, one [non standard] > return path, directly to the provider's screen, IS allowed under the > exception, but I don't see where the rule specifically allows even that > deviation from the standard... it just seems to be inferred because the DDE > service would make no sense without a return path. But can that return > path also be to a cache file, for later display... or to a print spooler, > bypassing the display all together? ... or downloaded to a file, as your > system offers to do? Presumably, the provider's system can do whatever it > likes with the returned data, once it is in his possession. > > The problem may even be more complicated, because the [apparently] > permitted non-standard payor response (directly to provider's screen) > appears to be allowed ONLY because the initiating transaction came to the > payor via DDE. If a 270 was sent as a normal EDI transaction, I don't > > think it would be legal for the provider to go to a web address some time > later to view the eligibility response as a screen image. In order for > that mode of delivery to be legal, I would think that the "270" data would > have to have been hand-keyed into a DDE screen. Does this non-standard > return path allowance only apply, then, to paired Q-A transactions like the > 270/271? If a claim were submitted via DDE, and the payor wanted to > instantly adjudicate it and return the DDE-screen-equivalent of an 835, > would that be permitted? Does the interaction have to be "real time" to > qualify under the DDE exception, or can the response to a DDE transaction > be delivered hours/days/weeks later... and still be excused from data > format requirements? > > Peter... any ideas? > > -Chris > From Peter's white paper: > Direct data entry §162.103 Direct data entry means the direct entry > of data (for example, using dumb terminals or web browsers) that is > immediately transmitted into a health plan's computer2. > Preamble quotation on what DDE permits: The “direct data entry” > process, using dumb terminals or computer browser screens, where the data > is directly keyed by a health care provider into a health plan’s computer, > would not have to use the format portion of the standard, but the data > content must conform. > Preamble quotation on what DDE does not permit: If the data is > directly entered into a system that is outside of the health plan’s system, > to be transmitted later to the health plan, the transaction must be sent > using the full standard (format and content). > > > > > At 03:12 PM 5/3/02 -0600, Owens, Kris wrote: > > >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] > > Christopher J. Feahr, OD > http://visiondatastandard.org > [EMAIL PROTECTED] > Cell/Pager: 707-529-2268 > To be removed from this list, go to: http://snip.wedi.org/unsubscribe.cfm?list=business and enter your email address. 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/. Posting of advertisements or other commercial use of this listserv is specifically prohibited.
