I think there is a very good chance that you will have to submit/process non-standard codes (assuming you mean ICD-9 or some other type of code) in a HIPAA "compliant" message.. The code set validation will have to be done on a per code and date of occurrence combination. It will be entirely possible that a HIPAA compliant message will be required using non-standard codes. The code set used must be applicable to the date of occurrence. In the case of a diagnosis, the date of onset, I would assume. So if an onset date was one day before the HIPAA compliance date, the non-standard code would be sent when the HIPAA claim was created after the compliance date BECAUSE that code would be applicable at the time of onset...
ginal Message----- From: Owens, Kris [mailto:[EMAIL PROTECTED]] Sent: Thursday, May 23, 2002 11:06 AM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: RE: HIPAA code sets update synchronization This is not an easy process, but really, it is an issue that exists today, changes to code sets have been instituted and not everyone in the chain is current - just different code sets. What we have instituted at our Healthplan is a twice yearly audit of claims that are denied for invalid coding - we then look at those claims and determine what the issue is - entry errors, education issues for the providers, contracting issues, system changes, etc. and take the appropriate action to correct the situation. For us, as often as not it is additional communication that needs to be done. Kris Owens Senior IS Project Manager - HIPAA Project Presbyterian Healthcare Services Albuquerque, NM 505.923.8108 [EMAIL PROTECTED] "There is no meaning in isolation" -----Original Message----- From: George Kaye [mailto:[EMAIL PROTECTED]] Sent: Wednesday, May 22, 2002 2:21 PM To: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: HIPAA code sets update synchronization Kumar, Good question. I have been trying to piece this together for several months now and it does not appear that there is a simple solution. Additionally there has been very little feedback from the listservs on this issue. I am thinking that it would be nice if there was a single annual or bi-annual date that could be the synchronization point for ALL code sets (medical and non-medical) in which they would be adopted as the HIPAA standard code values. That may not work for some codes, but I think the code set maintenance organizations need to collaborate and come up with a solution amongst themselves. Perhaps a new subgroup in WEDI? >>> "Kumar Sivaraman" <[EMAIL PROTECTED]> 05/22/02 02:01PM >>> Hi All, On the subject of HIPAA code sets I wish to request your comments on the following. Problem statement ----------------- HIPAA mandates that in order for a transaction to be HIPAA-compliant, the value of certain data items must be validated to be contained in an instance of a code set that was "valid within the dates specified by the organization responsible for maintaining that code set". An "instance" of a code set contains the set of all valid values for a specific data item at a specific point in time - for example, the set of all valid zip codes for the US as at 1-Jan-2000 is contained in the code set instance published by the issuing authority for zip codes with an applicable date of 1-Jan-2000. The authorized issuing authority for a specific code set is responsible for making new instances of that code set available to parties which require to validate against that code set. There is necessarily a delay between the actual publication date of a new instance of a code set, and the installation of that code set instance on a specific computer system ready for use validating transaction data values. This gives rise to the likelihood of the following problem occurring regularly in operational systems: 1. A transaction set is originated in trading partner A (TP-A). 2. A data value in that transaction set is validated by TP-A to be correct, as it is contained in the current code set instance in use by that trading partner. 3. TP-A transmits the transaction set to TP-B. 4. TP-B validates the same data value, which fails validation because a different code set instance is in use by TP-B. Questions --------- a) How does the healthcare industry address this issue? b) Do code set issuing authority indicate any time frame by which a new code set (or a new value in a code set) becomes effective and ready for use in transactions? c) The magnitude of this is much bigger for clearinghouses. How would they address this? Thanks, Kumar Sivaraman Business Analyst - Standards SeeBeyond Technology Corp. |-----Original Message----- |From: Dhandapani, Palani (Cognizant) [mailto:[EMAIL PROTECTED]] |Sent: Tuesday, May 21, 2002 11:06 AM |To: Winston, Mike K.; Dhandapani, Palani (Cognizant); |[EMAIL PROTECTED]; '[EMAIL PROTECTED]' |Subject: RE: Date of service | | |Interesting. | |Coming to claims that are already in the system/application |prior to HIPAA |switch being turned on, we may not be able to apply HIPAA edits for two |reasons : 1. Claims may have non standard code sets that may not pass |Level-5 HIPAA edits (code set validation) 2. The claim may be |have come in |the non-standard format, so there is no need to apply Level-1 |to Level-6 |edits. Folks, please correct me if I am wrong. | |Now, I have one question to the Group: | |What are the different scenarios for processing claims after |Oct 2003? I |have listed here some of them. Please add if I have missed |anything or if I |am wrong. | |Scenario-1 : Claims with standard code sets in X12 4010 format | |Option : No problem as the HIPAA compliant application will be able to |handle it happily. | |Scenario-2 : Claims with Standard codes in Paper format | |Option-1: Accept, adjudicate and send Paper EOB. Only Level-5 |HIPAA Edit in |the application. |Option-2: Send 835 ERA, if provider requests. (Make sure all minimum |required information is available for generating 835 as |response to Paper |claim). Level-5 edit in the application and other HIPAA edits |for 835 at the |outbound side. | |Scenario-3 : Claims with non-standard codes in Paper format. | |Option-1: Accept, cross walk, adjudicate and send paper EOB. |Option-2: Notify providers to stop sending claims with |non-standard codes |from a cut-off date prior to HIPAA compliance date. | |Am I missing anything ? | |Thanks |Palani |Cognizant Technology Solutions |201-678-2772 | |-----Original Message----- |From: Winston, Mike K. [mailto:[EMAIL PROTECTED]] |Sent: Tuesday, May 21, 2002 7:46 AM |To: 'Dhandapani, Palani (Cognizant)'; [EMAIL PROTECTED]; |'[EMAIL PROTECTED]' |Subject: RE: Date of service | | |Thanks, | I do not see how Hipaa can expect edits to be applied to a |claim adjustment |when the original claim was processed before the edits were |established. |Does Claim generation refer to the date the claim was generated by the |provider, if so then claims already in our system prior to the |Hipaa switch |being turned on do not have to meet the Hipaa edits. Correct? | | |Mike Winston |Business Systems Analyst |Trigon ISD |Ph (804) 354-4521 |Fx (804) 678-0452 |[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 the intended recipient, you are hereby |notified that |any dissemination or copying of 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: Dhandapani, Palani (Cognizant) |[SMTP:[EMAIL PROTECTED]] |> Sent: Tuesday, May 21, 2002 10:15 AM |> To: Winston, Mike K.; [EMAIL PROTECTED]; '[EMAIL PROTECTED]' |> Subject: RE: Date of service |> |> There are two components here. Medical code sets and |NonMedical code sets. |> |> For Non-medical code sets, the Data of service is the |reference. So we |> should use the medical codes that are valid on the date of service. |> |> For Non-medical code sets, the date of Claim generation is |the reference. |> |> Please refer to the following regulation: |> |> 162.1000 |> |> (a) Medical data code sets: Use the applicable medical data code sets |> described in section 162.1002 as specified in the implementation |> specification adopted under this part that are valid at the time the |> health |> care is furnished. |> |> (b) NonMedical data code sets: Use the non medical data code sets as |> described in the implementation specifications adopted under |this part |> that |> are valid at the time the transaction is initiated. |> |> Hope this helps. |> |> Thanks |> Palani |> Cognizant Technology Solutions |> 201-678-2772 |> |> |> -----Original Message----- |> From: Winston, Mike K. [mailto:[EMAIL PROTECTED]] |> Sent: Tuesday, May 21, 2002 6:37 AM |> To: [EMAIL PROTECTED]; '[EMAIL PROTECTED]' |> Subject: Date of service |> |> |> I know this was discussed, but I want to confirm that |opinions have not |> changed. When Hipaa is in effect we are planning on using |the claims Date |> of |> Service to determine if the claim needs to be fully compliant or not, |> example: Claim was submitted prior to Hipaa live date with |a "Homegrown |> code" the 835 goes out after Hipaa is implemented with the |non-compliant |> code. or Claims that were not subject to any crossfoot edits prior to |> hipaa |> if adjusted will be sent out on the 835 but will not crossfoot. |> |> We are making the logic based on the claims date of service not the |> processed date. Any thoughts? |> |> Mike Winston |> Business Systems Analyst |> Trigon ISD |> Ph (804) 354-4521 |> Fx (804) 678-0452 |> [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 the intended recipient, you are |hereby notified |> that |> any dissemination or copying of 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. |> |> |> |> |> |> << File: InterScan_Disclaimer.txt >> | 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. 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. ---------------------------------------------------------------------------- -- CONFIDENTIALITY NOTICE: This message is intended only for the use of the individual or entity to which it is addressed and may contain information that is privileged, confidential or exempt from disclosure under applicable law. If the reader of this message is not the intended recipient or the employee or agent responsible for delivering the message to the intended recipient, you are hereby notified that you are strictly prohibited from printing, storing, disseminating, distributing or copying this communication. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank You, Antares Management Solutions. ============================================================================ == --- 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]
