Yes, your assumption is correct (and this isn't a new issue). Medical data code sets (e.g. CPT4, ICD9) are commonly stored in databases with "effective" and "terminated" dates so this hasn't really ever been a problem to my knowledge. Other codes (e.g. Revenue Codes) are also commonly stored in databases with "effective" and "terminated" dates. I have not heard of an experience referenced by Kepa. We have generally found the codes to be announced at least 90 days prior to effective use.
John Carter Healthcare Administration Technologies, Inc. www.hatinc.com -----Original Message----- From: Dekker, Cory [mailto:[EMAIL PROTECTED]] Sent: Wednesday, May 22, 2002 12:13 PM To: [EMAIL PROTECTED] Cc: '[EMAIL PROTECTED]' Subject: RE: HIPAA code sets update synchronization Kumar raises some critical questions, but I'm concerned we might have an iceberg here. On page 50370, the 8/17/2000 Federal Register, Subpart J (Code Sets), (162.1000) states: (a) Medical data codes sets [ must be validated as of ] the time the health care is furnished. (b) Non-medical data code sets [ must be validated as of ] the time the transaction is initiated. Scenario: John is treated by small-town Dr Fred on Tuesday, 9/30/03. After repeated attempts and much training, Dr Fred's office manager (Mrs Fred) finally successfully enters John's claim into their brand new HIPAA-compliant computer system on Monday, 10/20/03, generating an 837 transaction. The system and software came with the new clearing house service that they've signed-up for, and every Saturday night, the system automatically (wow, cool) bundles up the claims and sends them off via dial-up to the clearing house. Sunday, 10/26/03, the CH gets the bundle. In turn, it's re-bundled and scheduled for transmission to John's Health Insurance company. However, the CH only sends to John's company on Saturday mornings at 1am. Saturday morning, 11/1/03, John's Health Insurance company processes and validates the transmission from the SFTP bundle that was uploaded. Now, if I understand everything above correctly, on November 1st, when the payer validates their newest transmission, they must validate all Non-medical codes against the valid code sets on October 20th, and all Medical codes as of September 30th. So not only do we need to have the proper codesets, current (to different months, in some cases), but we must maintain multiple versions of the codesets, and validate each code against the appropriate version, based on one of 2 different dates (the Date-of-Service date stamp for medical codes, or the BHT date stamp for non-medicals)? Is this correct? Is it really this complicated? How are folks addressing these issues? -Cory Cory Dekker GWL-EBIS HIPAA Project Analyst 303/737-2022 -----Original Message----- From: Kumar Sivaraman [mailto:[EMAIL PROTECTED]] Sent: Wednesday, May 22, 2002 12:02 PM To: 'Dhandapani, Palani (Cognizant)'; Winston, Mike K.; [EMAIL PROTECTED]; '[EMAIL PROTECTED]' Subject: HIPAA code sets update synchronization 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=codeset 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=codeset 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=codeset 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.
