HIPAA 4010 to 5010 and ICD-9 to ICD-10: more than just a conversion

A few weeks ago I provided a few examples about problems like converting HIPAA 4010 messages into HIPAA 5010, and about the complexity of migrating from the older ICD-9 set of diagnostic codes to ICD-10. Considering the mandated compliancy timeframes for the switch from 4010 to 5010 and ICD-9 to ICD-10, it is reasonable to assume that many players in the healthcare industry will tend to associate both switches: migrating from ICD-9 based HIPAA 4010 to ICD-10 based HIPAA 5010. If you have followed the two posts referenced earlier, you'll realize that we are not talking just about a message "conversion" here; the migration involves more than just switching to a new grammar, especially when it comes to ICD-9 to ICD-10 conversions. That's why at DataDirect we always talk about our Data Integration Suite rather then the individual components of the suite: XML Converters provides a great way to abstract the low level EDI (and more) syntax into an XML data model and vice-versa; but they are not able to add semantics to the conversion; DataDirect XQuery provides a great way to manipulate an XML data model creating a new one that may where the original information has been modified or enriched (for example accessing additional data sources, like a database) according to specific semantics. If you put the two modules together you have a solution (Data Integration Suite) that is able to take care of complex conversion/integration problems which involve both the need of manipulating EDI syntaxes and handling semantics specific to the domain in question. So, what am I getting at? I would like to create a solution that converts HIPAA 4010 to 5010 and also takes care of migrating ICD-9 codes (possibly) contained in the 4010 message to ICD-10 codes in the 5010. And one way to do that is to mix the examples provides when talking specifically about 4010 to 5010 and ICD-9 to ICD-10. Remember how the solution based on the XQuery Update Facility and XML Converters to move from 4010 to 5010 looks like? Well, let's add a couple of lines to that solution:[cc lang="xquery"]copy $doc5010 := . modify ( rename node $doc5010/HIPAA/ISA/ISA11-InterchangeControlStandards as QName("", "ISA11-RepetitionSeparator"), replace value of node $doc5010/HIPAA/ISA/ISA12-InterchangeControlVersion with "00501", rename node $doc5010/HIPAA/ISA/ISA12-InterchangeControlVersion as QName("", "ISA12-InterchangeControlVersionNumber"), rename node $doc5010/HIPAA/ISA/ISA15-UsageIndicator as QName("", "ISA15-InterchangeUsageIndicator"), insert node <GS08-VersionReleaseIndustryIdentifierCode>005010X222</GS08-VersionReleaseIndustryIdentifierCode> before $doc5010/HIPAA/GS/GS08-VersionReleaseIndustry, delete node $doc5010/HIPAA/GS/GS08-VersionReleaseIndustry

for $icd9 in $doc5010//HI/*/*[ends-with(local-name(.), 'IndustryCode')] return replace value of node $icd9 with local:get-closest-icd10-from-icd9($icd9) ) return $doc5010 [/cc] Notice the additional 2 lines at the bottom of the query: they instruct the conversion to replace the occurrences of "industry code" entries in the 4010 messages with ICD-10 values computed by the "get-closest-icd10-from-icd9()" function. That function is where we need to specify the semantics of the conversion in our case; one (over-)simplified approach is to just return the first matching ICD-10 diagnostic code (assuming there is one); we do that using the approach described in the ICD-9 to ICD-10 post, using a mapping table exposed by a database:[cc lang="xquery"]declare function local:get-closest-icd10-from-icd9($icd9 as xs:string) as xs:string { let $mapping := collection("ICD9-ICD10")/ICD9-ICD10[ICD-9 = $icd9] return if($mapping/APPROX = false()) then (: exact match :) $mapping/ICD-10 else if($mapping/NOMAP = true()) then (: no match; just return ICD-9 :) $icd9 else (: approximate match; pick one :) $mapping[1]/ICD-10 };[/cc] Of course different and more complex mapping semantics can be expressed, but this example illustrates what I was mentioning earlier: using XQuery and XML Converters together (Data Integration Suite) we are able to be abstracted from the syntax details of the incoming (and outgoing) EDI messages, and to specify potentially complex semantics to obtain the transformation and data enrichment needed by the process. More to come along these lines; in the next post we'll see how to use Data Integration Suite to take care of a transformation that also involves using XML Converters to do HTML to XML.