Joanne, Just a small point of clarification. My comments re changing versions were in response to the question about transaction set version changes and not code set version changes. Even with no direct hands-on experience in dealing with the medical code sets, I can appreciate that code set version change management is a whole different animal than transaction set version change management. That's why my comments mentioned the role of good commercial EDI management systems in facilitating transaction set version change management.
Rachel -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Monday, October 14, 2002 12:03 PM To: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: RE: Code set effective dates While the technical issues of version control may not be complicated, the human issues of managing several different versions with varying grace periods can be very complex (or at least, frustrating). Our state SNIP subgroup has prepared a white paper in support of coordinating the release and effective dates of the major code sets. I would encourage other work groups to do the same. If simplification is the goal -- this is one step in the right direction (even if the goal seems lofty). Joanne Becker, RHIT, CCS Iowa SNIP Coding/Transaction Workgroup Original Message: ----------------- From: Rachel Foerster [EMAIL PROTECTED] Date: Mon, 14 Oct 2002 11:31:39 -0500 To: [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: RE: Code set effective dates The HIPAA Electronic Transaction Final Rule sets forth the requirement for effective dates for codes set thusly: Subpart J-Code Sets ? 162.1000 General requirements. When conducting a transaction covered by this part, a covered entity must meet the following requirements: (a) Medical data code sets. Use the applicable medical data code sets described in ? 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 nonmedical data code sets as described in the implementation specifications adopted under this part that are valid at the time the transaction is initiated. The other issues you raise re change management and version control will of course have to be addressed at the time new versions of the HIPAA specifications are adopted. Change management and version control are not complicated but must be addressed in rules/requirements, etc. when moving from one version to a newer one. Outside of HIPAA, most industries recognize the business need to support multiple versions of any given EDI transction set. Therefore, good commercial EDI management systems have this capability (handling multiple versions of a transaction set/map by trading partner) designed into them. It's truly not a big technical detail, just something that must be managed. Change management/version control is not unique to EDI and transcends most software systems/tools. Rachel Foerster Principal Rachel Foerster & Associates, Ltd. 39432 North Avenue Beach Park, IL 60099 Voice: 847-872-8070 Fax: 847-872-6860 eMail: [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> http://www.rfa-edi.com -----Original Message----- From: Christopher J. Feahr, OD [mailto:[EMAIL PROTECTED]] Sent: Saturday, October 12, 2002 6:24 PM To: Ratayski, Dawn; 'Ossont, Dawn x405'; '[EMAIL PROTECTED]' Cc: [EMAIL PROTECTED] Subject: RE: Code set effective dates Dawn, Please pardon the cross-post to "transactions", but this reminds me of a couple other version-date issues that I'd like to bounce off the transaction gurus. If the code-set version is determined by "date of service", what will drive the choice of code-set for transactions sent in advance of the actual service... like the 270? In any case, it appears that senders will have to maintain current and [possibly several] previous code-sets so that claims submitted [up to a year, possibly] after a code-set update can be created with the codes that were in effect on the date of service... right? My other question is regarding the correct transaction version to use, which (if I understand correctly) is driven by the date of the transaction, as opposed to the service-date. So, does this mean that a claim REsubmitted after the required implementation date of new transaction version, would have to be reformatted for the new transaction version? Would there ever be a scenario in which a sending system's translator or a receiving system's validator would have to be able to support BOTH old and new transaction versions? If so, which date-field in the interchange determines the choice of transaction version? Thanks, -Chris Christopher J. Feahr, OD Optiserv Consulting [For the vision care industry] Santa Rosa, CA 707-579-4984 707-529-2268 (cell/pager) http://VisionDataStandard.org http://Optiserv.com 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.
