Michael, I'm not arguing that you are "incorrect" in your interpretation, but your item #3 illustrates one of the fuzziest issues with DDE and something that needs to be cleared up soon. It is essentially that the "DDE exception" describes the provider's "send" transaction, but is silent on the requirements for the payor's "response" transaction. In an interactive session, every "send" triggers an answering transaction until the "DDE session" is terminated. The Transaction Rule, however, is message-centric and does not recognize interactive "sessions" like this, and therefore cannot speak about a session's "beginning" or "ending". A strict interpretation of the Transaction Rule would not even permit the payor to send an answering transaction (e.g., a 271) back to a provider's DDE terminal, because payors do not have any DDE-exception relief in the rule... only providers have this. Of course, that would defeat the purpose of DDE... nevertheless, it needs to be clarified.
I'm also very concerned about your #2... which is probably also "correct", but very anti-standard from the provider's point of view. This appears to suggest that you can have any old non-standard fields you like in a DDE application, as long as you identify the "real standard" fields with a unique color. The rule says that resolution of "the transaction" (whatever that concept is in a DDE session) "cannot depend" on those additional/non-standard fields... but why else would they be there? In many cases, you cannot even transmit the web-form without populating the non-standard fields correctly. Regards, Chris At 10:37 AM 6/7/02 -0400, Fields, Michael wrote: >Lisa, > >The client I am working for also offers a DDE application for >authorizations(278). We are going through the same process of rewriting >the 278 application. Here are some responses to your questions based on >our current understanding. > >1. You should take a look at the draft for the 274 transaction. In the >future the 274 will be used for such updates of provider information. It >may be a good idea to design your system to anticipate this. Follow this link: > ><http://www.wpc-edi.com/conferences/healthcare.html>http://www.wpc-edi.com/conferences/healthcare.html > >Click on guest to log in as a guest. Then click on the topic to the left >titled "#103 Health Care Provider Information". You should then see a >link to the right to download the draft of the 274 transaction. If you >plan to leave the provider update portion within the 278 application, I >would use a technique to designate this part of the application as >non-standard for the 278. See my response for the next question. > >2. The HIPAA bill states that if any extra information (not part of the >HIPAA specification) is presented in a DDE system, that this information >must be clearly denoted as non-standard data. The HIPAA bill is unclear as >to the acceptable approaches in denoting this extra information. We have >gotten feedback from HHS that using a different color, flagging with a >footnote, or placing these items in a separate section of the screen would >be acceptable. We get the impression that this is fairly flexible and any >reasonable approach to clearly differentiating the standard from >non-standard data would give you compliance. > >3. Our understanding of being data compliant on the response is that the >required fields on the 278 response should be available, but you don't >necessarily have to dump all of the response information at the user at >once. We plan to provide limited information on the immediate response, >such as the authorization number and any truncated dates or authorized >amounts. The user can then follow a link to view all of the response >information for the authorization. Our understanding is that the ordering >or layout of the response information does not have to follow the IG. > >4. We also have a required set of pre-certification questions that we >must ask for our business purposes. We are denoting these questions as >non-standard HIPAA data as I mentioned for question #2. > >Thought you might be interested .. we had an issue as to what the >requirement was for DDE systems as far as displaying code sets .. whether >we could provide our own descriptions for some codes. Here is the >response we got from Stanley Nachimson: > >"The critical item is that you provide at least the HIPAA codes. >Additional explanatory information is optional - it can be shown, but is >certainly not required. Nor can the additional information put >restrictions on the codes which would be in conflict with the IG or the >code set maintainer." > >If anyone thinks we have made any invalid assumptions on any of the >responses here, please repond to this group ... > > __________________________________________ >| Michael Fields >| <http://www.utopiansoft.com>Utopian Software Concepts >| [EMAIL PROTECTED] >\__ > >This message, including files attached to it, may contain confidential >information that is intended only for the use of the ADDRESSEE(S) named >above. If you are not an intended recipient, you are hereby notified that >any dissemination or copying of the information contained in this message, >or the taking of any action in reliance upon the information, is strictly >prohibited. If you have received this message in error, please notify the >sender immediately and delete the message from your system. Thank you. > > -----Original Message----- >From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] >Sent: Thursday, June 06, 2002 4:36 PM >To: [EMAIL PROTECTED] >Subject: X12 278 - DDE Questions >We are a business associate and currently offer a DDE online application >for Health Care Services Review Request & Response (278). Since we are a >BA on behalf of our clients in which are CEs we are rewriting the >application to be compliant with the 278 data content and conditions. I >have several questions that are not addressed in the HHS FAQ's or WEDI >White Paper on DDE. I am hoping some of you can help steer me in the right >direction. > > * We currently have a provider update page that we offer to the health > care providers using our application. Once the provider is selected they > can review their demographics and update if appropriate. Are we compliant > if we continue to provide this but only let them update the standard data > content under Loop 2010E Service Provider? Or can we direct them through > a link to another application to review and update their data? > > * We have several disclaimers and instructions listed throughout the > application. Are disclaimers allowed? Or is this considered non-standard > data content? > > * How do you handle the response on a DDE application? Can you return > limited data in the appropriate order? Or must you return all the > required data that has been entered along with the required response data? > > * Our application will take the provider into the medical criteria. > They will be asked a series of clinical questions to complete the > precertification process. Are we allowed to do this as long as we have > the users answer the criteria after the appropriate code or service has > been entered (i.e. following content and order of the 278)? > > >Thank you, > > > >Lisa > > > > > >Lisa La Mont > >Project Manager, IS/IT & HIPAA > > > >Beech Street Corporation > >25500 Commercentre > >Lake Forest, CA 92630 > >(949) 672-1703 > >Fax: (949) 450-4164 > >Visit Our Website: <http://www.beechstreet.com>http://www.beechstreet.com > > > > bfbc8e.jpg > > > > >************************************************************************************************************* >Confidentiality Statement - This Email is confidential. The information is >intended only for the person or entity to which it is addressed and may >contain confidential and/or privileged material. Any review, >retransmission,dissemination, or other use of, this information by persons >or entities other than the intended recipient is prohibited. If you are >not the intended recipient, you must not disclose or use this information >contained in it. If you have received this Email in error, please contact >us immediately and delete (destroy) the document. >************************************************************************************************************* > > Christopher J. Feahr, OD http://visiondatastandard.org [EMAIL PROTECTED] Cell/Pager: 707-529-2268
<<inline: bfbc8e.jpg>>
