DataDirect HIPAA/ICD Upgrade Toolkit

The Looming Problem in Healthcare EDI

On January 15, 2009, the United States Department of Health and Human Services (HHS) released the final rules for the updated X12 transaction sets, version 005010, to used in conjunction with the Health Insurance Portability and Accountability Act (HIPAA). The final compliance date is January, 2013. At the same time, the International Classification of Diseases (ICD) standard is also being bumped, from ICD-9 to ICD-10. This compliance date follows closely on the heels of the first, October, 2013.

From the viewpoint of the people who use the data, there are many good reasons for this change. In the last six years or so between HIPAA 4010 and 5010, we've learned a lot about who needs what data and when. However, the actual changes to the data format are more of the evolutionary, and not revolutionary, type.

However, the ICD-9 to ICD-10 change is a radical step:

• It's been 30 years since the ICD-9 list was first developed ICD-9 is embedded much deeper into systems - the 36 years from 1977 to 2013 means that a junior programmer who wrote ICD-9-related code at the start of his career is probably now the CTO facing the consequences of a change he never planned for an entire career earlier.
• The list for ICD-10 is far more detailed, at almost 10× the length The numbering system has changed, the number of diagnostic codes increased, individual codes are more detailed.
• There are generally not 1:1 mappings between ICD-9 and ICD-10 Although some codes in their old classification map directly to codes in the new, most don't. Sometimes there is a series of codes, sometimes there are alternatives that will takes external information to chose from, and sometimes there are no direct alternatives.

This all makes for challenges for those working with either of these standards, and since the "HI" segment of several HIPAA transaction sets can directly refer to ICD-9 or ICD-10 codes, these problems actually intersect. How can we account for the changes in where data has been moved, or where new data must be extracted from other sources to augment the existing feed?

Upgrading HIPAA-4010 Systems

Transforming data in HIPAA 4010 X12 files and translating ICD-9 codes has been covered in individual blog entries on the XML Connections Blog over the past few months:

• HIPAA 4010 to 5010: how the XQuery Update Facility helps
• ICD-9 to ICD-10: what is that about, and how can data integration tools help
• HIPAA 4010 to 5010 and ICD-9 to ICD-10: more than just a conversion

The hardest part about writing a book is that first sentence. It is similar with data conversion projects. When there is so much to convert, where does one begin?

To help out, DataDirect Technologies is now giving away the DataDirect HIPAA/ICD Upgrade Toolkit, which includes the following:

Tranforming HIPAA 4010 to 5010 with XQuery and XML Converters

• XQuery source for upgrading each of the 10 transaction sets from the 4010 version to the equivalent 5010 version
• 50 sample 4010 files to use with the above
• The ICD-9 to ICD-10 maps
• A sample tool to compare the changes between ICD-9 codes and their closest ICD-10 analogs, with HTML output
• An XQuery program which will read a HIPAA file containing ICD-9 codes and report on any potential conversion troubles with ICD-10
• An XQuery program to read a HIPAA EDI file, and convert it from 4010 to 5010 and from ICD-9 to ICD-10 simultanously

What does XQuery have to do with HIPAA? Well, DataDirect XML Converters make EDI behave like XML. And XQuery is really good at augmenting, splitting and rearranging XML. The two together let a relatively small XQuery program do big things.

For example, here is the complete program to read in a HIPAA 4010 270 file, update it to the 5010 structure, and return the results. Notice the little "method=EDI:hipaa=yes" at the start? That tells the XQuery engine that the output is going to be EDI, just like the input.

[cc lang="xquery"]declare option ddtek:serialize "method=EDI:hipaa=yes:long=yes"; copy $doc5010 := . modify ( rename node $doc5010/HIPAA/ISA/ISA11-InterchangeControlStandards as "ISA11-RepetitionSeparator", replace value of node $doc5010/HIPAA/ISA/ISA12-InterchangeControlVersion with "00501", rename node $doc5010/HIPAA/ISA/ISA12-InterchangeControlVersion as "ISA12-InterchangeControlVersionNumber", rename node $doc5010/HIPAA/ISA/ISA15-UsageIndicator as "ISA15-InterchangeUsageIndicator", insert node 005010X279 before $doc5010/HIPAA/GS/GS08-VersionReleaseIndustry, delete node $doc5010/HIPAA/GS/GS08-VersionReleaseIndustry, insert node 005010X279 after $doc5010/HIPAA/TS_270/ST/ST02-TransactionSetControlNumber, delete node $doc5010/HIPAA/TS_270/GROUP_1/GROUP_2/PER, for $eq01 in $doc5010/HIPAA/TS_270/GROUP_1/GROUP_2/GROUP_3/EQ/EQ03-CoverageLevelCode[. != "FAM"] return replace value of node $eq01 with "FAM", delete node $doc5010/HIPAA/TS_270/GROUP_1/GROUP_2/GROUP_3/III[III01-CodeListQualifierCode != "ZZ"], for $gp3 in $doc5010/HIPAA/TS_270/GROUP_1/GROUP_2/GROUP_3 return delete node $gp3/III[III01-CodeListQualifierCode = "ZZ"][position() > 1] ) return $doc5010[/cc]

Because the XQuery engine in the Data Integration Suite supports the XQuery Update Facility (XUF), instead of having to map individually every "old" part of the document to its place in the "new" scheme of things, we can just list the parts that change, as "replace," "rename," "insert" or "delete". Anything we leave alone goes through untouched; and really, not everything between 4010 to 5010 has changed.

How might you use them? Suppose the next process in line from yours has already upgraded to 5010, and wants to see some of your sample output. Or perhaps someone sending data to you is still sending 4010, but you're all set for 5010. In these cases, having a way to upgrade the 4010 quickly and easily is a real win.

Dealing With Your ICD-9 to ICD-10 Issues

It is valuable to remember that XQuery is good at augmenting information, and the blend of an XQuery engine with an intelligent mediator sitting atop wire-protocol relational database drivers means that data can be easily mixed and merged from EDI, relational tables and XML. Data can be streamed in (read) or streamed out (written), to XML, EDI, relational databases, or other targets with equal ease and scalability.

The programs that deal with ICD-9 to ICD-10 are a good example at enhancing XML data using relational tables as references. XQuery is very powerful at dealing both with tree-like data, as in XML or EDI, and relational data. The ICD-9, ICD-10, and 9-to-10 maps are all stored as relational data. This gives us the fast lookup speed over regular tables that relational databases provide, with a minimum of coding. A small piece of code like this: [cc lang="xquery"]collection("ICD-10")/ICD-10[CODE = $icd10code][/cc] returns the ICD-10 record whose ICD-10 code value is in the $icd10code variable. There is no marshalling of data, no string substitutions, just the simple logic.

The XQuery programs including in the toolkit are sufficient to convert all of the samples that come with the 4010 documentation into valid 5010 files. Your mileage may vary - these are a good starting point, but no doubt for your specific application they will need some tweaking. But isn't it a whole lot easier to change someone else's working program, than to start from scratch?