ICD-9 to ICD-10: what is that about, and how can data integration tools help

In a recent webinar about issues that the healthcare industry will soon need to face about upgrading compliancy from HIPAA version 4 (4010) to version 5 (5010), we also mentioned how similar issues affect the upgrade from ICD-9 to ICD-10. The International Classification of Diseases and Related Health Problems (ICD) classifies diseases, symptoms, injuries and more. ICD codes are assigned to a category and identified by a code of six characters or less. ICD-9 was published in 1977, and it is currently widely used in the healthcare industry, for example when information between healthcare providers (e.g., your doctor) and healthcare plans (e.g, your health insurance company) is exchanged. As you can imagine, the classifications in ICD-9 are at this point fairly old and inadequate to track all the changes and improvements that have occurred in the healthcare space; the answer to that is ICD-10, which is going to become the new required standard in a few years from now (latest I've heard, the deadline is set to October 2013). OK, so, what's the problem? The problem is that in the next few years healthcare providers, plans and clearinghouses need to upgrade their systems to become compliant with ICD-10; and that's not a simple task; we are talking about changing systems that have been processing healthcare claim submissions for years, hundreds, thousands of them for each of us every year... An hiccup in that system would have enormous consequences. To complicate life (or to make it more interesting) there is no such thing as a 1-to-1 mapping between ICD-9 and ICD-10; ICD-10 is not just a superset of ICD-9; it's a totally different code set. There are cases in which an ICD-9 code has a precise match in ICD-10, but in most cases that's not true; in some cases there are only approximate matches available; in some others multiple possible matches exist; in some others only combinations of multiple ICD-10 codes can replace the information conveyed in a single ICD-9 code. Speaking of HIPAA, multiple versions, conversions and mappings, the question is inevitable: is there anything that the data integration technology in our DataDirect Data Integration Suite can do to help? The same way we help transforming HIPAA 4010 to HIPAA 5010, can we do anything about ICD-9 to ICD-10? To answer that question I started looking for more details; and I did find a lot of interesting information; for example, on HHS.gov you can find and download text files containing the full description of the ICD-9 and ICD-10 diagnostic codes, and the "set of general equivalence mappings". The mappings file is a bit cryptic to read, but it does contain all the details about exact/approximate/multiple-choice matches between ICD-9 and ICD-10 diagnostic codes. That gave us the idea to create a small application that given an ICD-9 diagnostic code returns information about its ICD-10 possible equivalent(s). And what could be better than storing those ICD code sets and mapping information in a database and then write a simple XQuery that processes ICD-9 codes and returns an HTML report on the ICD-10 equivalences? (OK, it's a rhetorical question, no need to answer it...) That's what we did, and using the XQuery Web service framework we automatically deployed the XQuery on our example server for you to try. The Web user interface you will see is just the default UI the XQuery Web service framework exposes automatically for testing purposes; it's not necessarily pretty, but it's excellent to run a few tests. For example, enter this set of ICD-9 diagnostic codes to see the different kind of ICD-10 equivalences you can obtain: 5992, 59983, 34621, 9171, 8962, 80600, V6441 This is part of the result you will obtain: You can experiment with it yourself; you will need to specify valid ICD-9 diagnostic codes to get meaningful results, of course. Do you want to know more about the technical details of what's going on there? A simple XQuery is responsible for processing your list of ICD-9 codes and for creating the HTML displayed in your browser; XQuery is relying on the exact same information I referenced above and stored in three tables in a relational database. I don't want to hide the XQuery from you of course; here it is:[cc lang="xquery"]declare option ddtek:serialize "method=html"; declare variable $ICD9-codes as xs:string external;

declare function local:cell($code, $desc) {

{ data($code) }{ concat(' (', $desc, ')') }

};

{ let $ICD9-sequence := fn:tokenize($ICD9-codes, "s*,s*|s*;s*|s*-s*|s+") for $case in $ICD9-sequence let $conv := collection("ICD.dbo.ICD9-ICD10")/ICD9-ICD10[ICD-9 = $case], $from := collection("ICD.dbo.ICD-9")/ICD-9[CODE = $case] return if(not($from)) then

else if($conv/APPROX = false()) then