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
