Build, protect and deploy apps across any platform and mobile device
Leverage a complete UI toolbox for web, mobile and desktop development
Automate UI, load and performance testing for web, desktop and mobile
Rapidly develop, manage and deploy business apps, delivered as SaaS in the cloud
Build mobile apps for iOS, Android and Windows Phone
Optimize data integration with high-performance connectivity
Connect to any cloud or on-premise data source using a standard interface
Build engaging multi-channel web and digital experiences with intuitive web content management
Automate decision processes with a no-code business rules engine
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:
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?
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:
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
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 := .
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
delete node $doc5010/HIPAA/GS/GS08-VersionReleaseIndustry,
insert node 005010X279
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]
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.
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?
Tony Lavino started in the 8-bit world with 6502 and Z-80 assembly. An experience with dBase II ignited Tony's passion for databases, and he soon found himself using Progress (now OpenEdge) 3.2J around 1987. He was so impressed, that he wanted to work for the company, and has since spent time either working for Progress or for its customers. Since 2002, Tony has worked on XML and EDI products, and now focuses on database drivers.
Copyright © 2017, Progress Software Corporation and/or its subsidiaries or affiliates.
All Rights Reserved.
Progress, Telerik, and certain product names used herein are trademarks or registered trademarks of Progress Software Corporation and/or one of its subsidiaries or affiliates in the U.S. and/or other countries. See Trademarks or appropriate markings.