[Z-Note:  This message is being resent to the two listservs, since it was initially rejected as a bit longish.  The length limit has been temporarily reset.]
 
Kumar,
 
Nicely put questions.  And, as we have seen, they raise many other issues, some of which have been getting kicked around the industry for some time now.  In fact, I believe that the American Hospital Association (AHA) wrote to the Secretary of DHHS just a month or two ago urging that future code set changes be coordinated.  And I remember making some related suggestions as part of some TCS NPRM comments I wrote back in 1997.  I also agree with many of the other responses that you have received thus far.
 
The externally maintained code values can change at any time, and don't require a 180-day notice.  A move to a different code set, or a major version change to an existing code set [like ICD-9-CM => ICD-10-CM], however, probably would require a new rule and at least a 180-day implementation period.  I have also seen external coding changes that were described as "retroactive".  In fact, I think that one of the most recently approved NUBC Manual changes is supposed to work that way, and another one is supposed to be "effective immediately".
 
I have also heard that X12 is considering changing their code-level maintenance processes so that the current internal code sets can be changed at any time and can also be used in older versions of the transactions.  I don't recall whether the proposal was that their maintenance be externalized, or if it was just that the X12 maintenance rules be changed to provide the necessary flexibility.  Either approach would certainly help with HIPAA.
 
One consideration I haven't seen noted yet is the need to retain previously valid codes for several years in order to support data warehouses and other multi-year data processing applications, as well as long-term research activities.
 
And I would clarify that the "Code Maintenance Committee" that maintains the Claim Adjustment Reason Codes and the Claim Status Codes is not part of the BCBSA, but is simply sponsored or hosted by the BCBSA in order to establish that these are, indeed, externally maintained code sets.
 
As for possible solutions, I think we will have to have multiple strategies.  Several years ago HHS was trying to standardize the use of data within their own department.  After doing many months of research, they reported back that they had found out that data is a four letter word, and that it is spelled "T-U-R-F"!  The point is that many different entities and constituencies are involved in the development and maintenance of the code sets used in the HIPAA transactions.  Some of these entities would probably be very happy to coordinate their maintenance schedules.  But I wouldn't expect maintainers of general code sets, such as Zip Codes, Area Codes, etc., to be interested in rescheduling their activities just to suit the needs of a single industry.  Similarly, I wouldn't expect international bodies such as the WHO (which maintains the ICD code set) or the ISO to be interested in aligning their activities to suit the needs of one country.  But some alignment is probably possible, and should be encouraged.
 
Another approach is to automate the update notification process.  About a year ago I tried to describe a scheme that would automate this process so that, at the beginning of any given day's processing, a computer could inquire of a national code set update tracking system whether any updates had been received since their last update query, and then automatically download any such changes and update their local code validation data bases as needed.  A certification organization such as Claredi would be an obvious choice for hosting such an update service, since they would need to track these changes anyway in order to carry out some of their certification functions.  And this service could also use a positive notification, or "push" model, if that would work better.  Some major health care industry publishers might also be interested in this business.
 
I think it would also be helpful to urge all code set maintainers to standardize their code maintenance data.  I.e., all of this works better, with or without HIPAA, if certain information is included as part of any code list.  This would include the code value, the code description, the date the code was added, the date the code is effective, and the date the code was retired, plus some others, no doubt.  Changes to both the code values and the code descriptions would need to be tracked.  Some code sets probably already have this data, but many don't.  For many small code sets it might even be practical to reconstruct the historical record.  At any rate, we can always start at some point and just note that any codes that are effective at that point in time were effective as of that date or earlier and maintain the more complete historical data going forward.
 
WEDI SNIP has established two Special Interest Groups (SIGS) related to code sets at various points within the Business Issues Subworkgroup (BI SWG).  One of these groups, led by Liza Moran and others, produced a Data & Code Sets Compliance white paper (WP), while a second one, led by Julie Thompson, researched how the code set update process worked.  Neither of these SIGS, which were recently merged, attacked the problem you described directly, although the Code Set Resolution SIG was probably headed that way.  But, with so many different entities involved in code maintenance, this is tough issue to attack successfully.  You pretty much have to accept that you are going to have very little influence, let alone control, over the activities of many of these entities.  Simply developing and maintaining a contact list becomes a major chore.
 
As a result of the current discussion, the BI SWG is revisiting this issue.  I would be surprised if there would be any problem with revising the scope of the current code sets SIG as needed to include these issues, or we could simply start a separate SIG, or a separate WP within the existing code sets SIG.  But I would hope that we could build on some of the prior work of the separate SIGS, and also draw on other reasonably current information resources, such as that on the Claredi site.
 
So, to sum up:
 
1)  I think that we could synchronize code set updates to a significant extent if we can have an open discussion of the considerations and give the code maintainers an opportunity to voluntarily synchronize and coordinate their processes.
 
2)  I think that we also need to identify a "minimum data set" that would be needed to track compliance with a code set,, given the expected compliance criteria, and encourage all code maintainers to provide that data as part of their official code lists.
 
3)  I think that we might have a valid business case for one or more national code set update services that could relieve several million covered entities of the need to track those update processes independently.
 
4)  I suspect that SNIP is a reasonable place to do some of this, given a sufficient quantity and quality of volunteer resources.  This could be done under the BI SWG, or it could be elsewhere in SNIP, or even a separate Transactions WG SWG.  The problem is getting a long-term commitment of the resources, since it could take several years to even start to show a difference, unless such cooperation were explicitly mandated.
 
Any other thoughts?
 
----- Original Message -----
 
From: "Kumar Sivaraman" <[EMAIL PROTECTED]>
To: "'Dhandapani, Palani (Cognizant)'" <[EMAIL PROTECTED]>; "Winston, Mike K." <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Wednesday, May 22, 2002 8:01 AM
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.

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.

Reply via email to