Tim Dietrich

Custom Software Developer

Home Services Portfolio Blog About Contact Newsletter

ICD-10 Research: Behind the Scenes

Here's a little background on ICD-10 Research, a search engine that I've developed to help healthcare professionals quickly and easily locate ICD-10 billing codes. icd10research.com

From 14k to 68k Codes by October 1st

It was through my database consulting work with clients in the healthcare industry that I became aware of the challenges that medical billing codes pose. Most of my clients using ICD-9 codes, and have been struggling with them for various reasons for many years. There are around 14,000 ICD-9 "CM" codes, which are used to diagnose patients. The codes are particularly important because they're also used for medical billing and to file reimbursement claims.

So when I learned that a new set of codes is on the way, and that there are a whopping 68,000 of them, I took notice. The new set of codes, which are known as "ICD-10" codes, are much more detailed - and as a result, they're also much more complicated. The Department of Health and Human Services (HHS) has published a regulation indicating that healthcare organizations that are covered by the Health Insurance Portability and Accountability Act ("HIPAA") have until October 1, 2015 to transition to the new ICD-10 codes.

The Complexity of the ICD-10 Data

I had heard rumors about how complicated the new codes are, and, after getting a copy of them, found those rumors to be true. The Centers for Medicare & Medicaid Services (CMS) provides the codes in a rather complicated XML format. This data set is one of the most challenging that I've ever had to work with. The XML document that contains the diagnosis codes is over 220k lines long, and is structured in such a way that putting its contents to use is very challenging. But after studying the document for awhile, and then loading it up into FileMaker so that I could slice and dice it, things started to come together. The document's data, and how it is structured, began to make sense.

An Idea Emerges

That lead to the idea of providing access to the data in the form of a search engine. The goal was to provide the healthcare community with a simple and easy way to locate ICD-10 codes.

And after many false starts, the search engine launched last Monday morning. And, based on early feedback from testers, it was re-launched today. The site is called ICD-10 Research, and if you'd like to have a look around, here it is: icd10research.com

The site provides visitors with the ability to search for codes based on keywords, as well as an option to "drill down" into the codes by clicking on code sections. At the code level, detailed information about both the code, it's parent code, section, related codes, and more is presented. In the process of developing the site, I learned more about medical billing codes than I ever imagined, and I have great respect for what professional medical billing coders must go through on a daily basis.

Behind the Scenes

Besides the ICD-10 data itself, one of the challenges in developing the site was making it simultaneously complete and fast. The latest version of the site uses a significantly re-designed FileMaker database to serve up the data. In fact, it took about 24 hours of batch processing to get the raw XML data into its current form - a form that allows FileMaker (or FileMaker Server, to be more precise) to easily handle both the ad hoc, keyword queries and the more structured requests for specific codes and code sections. FileMaker does remarkably well when faced with the task of serving up the data.

On the front end of the Web site is custom, hand-coded, PHP. I used the FileMaker's API for PHP, along with the open source FMWebFrame extension, to handle the integration with the FileMaker database. The site makes heavy use of FMWebFrame's caching abilities (which I've written about before). Browse the site, and you can see just how much of an impact the caching has. It's the best of both worlds: A dynamic, database-driven site, with the speed of static HTML.

The site consists of well over 40,000 dynamically generated pages, and Google has already indexed the majority of them. During the crawl, the impact on the Web server, and, perhaps more importantly, on FileMaker Server, was minimal. In fact, had I not known that they were crawling the site by looking at the Web logs, I wouldn't have know it was happening. So again, there's the importance of the caching.

The Future

I'm now working on an iOS app to complement the site. I've already developed a good portion of it using Xojo, and now that the site and the backend database are stable, I'm ready to wrap that up and get it submitted to the App Store.

If you have any questions about the site, the technology behind it, or if you need assistance with an ICD-10 related project, drop me a line. I'd love to hear from you.