ICD-9 to SNOMED Codes | Practice Fusion

This is the third in our series of blog posts that discuss the technology behind Meaningful Use, the Medicare and Medicaid EHR incentive program that provides financial incentives for the “meaningful use” of certified EHR technology to improve patient care. If you’re interested in joining our talented technology team, check out our Careers page.

Until Practice Fusion’s Meaningful Use 2014 certification, physicians using our EHR searched for and saved diagnoses using ICD-9 codes as the coding system. These codes were maintained and housed in a database built and maintained by Practice Fusion. Many users were requesting a fuller, more descriptive, quickly updated diagnosis code set, well before Meaningful Use Stage 2 requirements mandated that providers store patient diagnoses with SNOMED as the codeset.

But storing SNOMED codes like we stored ICD-9 codes seemed like it would just exacerbate the problem of maintaining a robust code set. Worse, mapping ICD-9 codes to SNOMED codes seemed like a huge and daunting undertaking. The amount of time and resources required just to do code mappings would take months, if not longer. A one-to-one code mapping between coding systems might have been a somewhat feasible problem to solve, but neither code system offered this. In many cases, ICD-9 codes mapped to multiple SNOMED codes. And in some extreme cases, ICD-9 codes didn’t map to any SNOMED codes.

Another hurdle was physician adoption. How could we introduce a new code system and expect our users to easily adapt their workflow? Most doctor offices are familiar with ICD-9 codes and what they mean, but hardly anyone knows SNOMED codes. Meaningful Use certification deadlines were approaching fast. Time was of the essence.

Our approach to this unique challenge is outlined below.

Managing the code systems

Practice Fusion incorporated the help of Health Language Inc. (HLI) LE Access Portal and Web Service solution. HLI offered not only ICD-9 and SNOMED code system mappings, but other code systems, such as ICD-10, which will become the new billing diagnosis codeset standard later in 2014. This offering was certainly an added benefit for Practice Fusion’s longer term needs. The ability to consume a web service and request search results containing both ICD-9 and SNOMED codes per result is an enormous time saver.

Additionally, HLI’s code sets were current, with monthly maintenance updates. Practice Fusion no longer had to maintain code sets ourselves, and even better, mappings between them. This alone saved Practice Fusion many months and resources, allowing us to focus on the remaining implementation hurdles.

Introducing SNOMED codes to our users

Next, we needed a service contract (not the legal kind) to get results from the HLI web service to our own UI. The results had to allow passing the matching diagnosis term, its relevancy to the user’s search term, and the code/descriptions of each code system mapped to each result. A DiagnosisSearchResult class that contains a collection of DiagnosisCodes provided an adequate web service contract:

Figure 1. Diagnosis Search Data Contract

With this contract, the UI calls a web service when users enter a search term and gets results that match a form of a primary matching diagnosis term, each code by code system, ordered by relevancy using the Score attribute also provided by the HLI web service.

Figure 2. Search results with predominant search term and both code systems displayed on UI

Note that the displayed results show the ICD-9 code preceding the result terms to avoid any disruption to what users are used to experiencing. This means users can effectively search both code systems in one shot. For physicians who were accustomed to searching by ICD9 code (for instance, 250 is the ICD-9 top-level code for Type II Diabetes), this was absolutely critical to their success using our EHR.

So, what about the search results that have only one code system mapping? Or the one ICD-9 code that is mapped to many possible SNOMED codes? Or the combinatory diagnosis, where multiple ICD-9 codes together make up the equivalent of a single SNOMED code? We had to answer those questions if this was going to be a compliant and useful feature; we also had to make some business decisions regarding user experience plus implement additional business logic in order to address these scenarios. Because other diagnosis features (add, update, delete diagnoses) were already under development, a diagnosis web service had already been added to the stack. Extending search capabilities through this existing web service allowed us to wrap the HLI web service, obtain the raw search results, and then process them using the additional business logic needed.

The following sections describe how we dealt with these additional challenges.

Excluded combinatory diagnoses

Combinatory diagnoses, where one code of a code system maps to many codes of another to provide a complete meaningful mapping, was a huge challenge. Luckily, this was not something that had to be addressed within the Meaningful Use deadline time frame. The direction for combinatory diagnoses became a business and usage problem.

Here is the approach we ultimately decided to take:

Filter out combinatory diagnoses from the search results
Leave the decision up to the user to determine whether a diagnosis individually describes a problem

With this approach, physicians could simply add more diagnoses to the chart note until she or he felt the diagnosis was complete.

Filtered out results that do not have at least one of each codeset

If an unpaired code returned in the search result, it simply did not make the cut. We immediately filtered these out, as they were not providing a SNOMED code that would allow compliance of Meaningful Use Stage 2 requirements.

Extrapolated the ‘OR’ conditions into many possible results

When an ICD-9 code is paired with multiple SNOMED codes, it means there is an ‘OR’ condition. In other words, the same ICD-9 code could map to many possible SNOMED codes. In order to accommodate this scenario, each possible mapping had to be treated as if it were a search result. If searching for the code “V50.2”, for example, the HLI response would contain 3 results:

Match = “V50.2”
Result 1
codeSystem = “ICD9CM”
code = “V50.2”
description = “Routine or ritual circumcision”

 Result 2  
      codeSystem = “SNOMED”  
      code = “176561009”  
      description = “Ritual circumcision”

  Result 3  
      codeSystem = “SNOMED”  
      code = “72310004”  
      description = “Circumcision”

After processing these results, our formatted response has only 2, each paired with the single ICD-9 result:

Match = “V50.2”
Result 1
codeSystem = “ICD9CM”
code = “V50.2”
description = “Routine or ritual circumcision”

      codeSystem = “SNOMED”   code = “176561009”   description = “Ritual circumcision”

 Result 2   **          **codeSystem = “ICD9CM”   **          **code = “V50.2”   **          **description = “Routine or ritual circumcision”

      codeSystem = “SNOMED”   code = “72310004”   description = “Circumcision”

Storing the SNOMED Code

With the code system mapping and management problem now elegantly solved with almost zero user impact, the next problem was in storing the diagnoses codes under the covers. Our database now needed to support persistence of two codes, and possibly more in the future (in fact, we already allowed custom codes to be entered by users, and that was a consideration in this design).

At this point, the search result description with ICD-9 code-description and SNOMED code description was available and ready to be persisted to our data store. Extending the existing diagnosis data model such that any one diagnosis can have many diagnosis codes by code system – essentially pulling out codes into their own table – resolved this. The data model is represented as follows:

_Figure 3. Extended diagnoses data model__ _

This “one Diagnosis to many Diagnosis Codes” model would allow as many codes by code system (or custom codes) to be stored as needed. Before this change, the ICD-9 code was stored in a specific column of our Patient Diagnosis table. Because this code displays to our users in both the search results and when displaying the Diagnoses on a patient’s chart, the use of this column could remain intact. This meant that whenever a diagnosis code came from the ICD-9 code system, we would continue to populate this column and pre-existing functionality would not be required to change to display patient diagnoses.

Additionally, the Diagnosis Name column would continue to be populated, but now this would be the value of the matched term of the search results, not necessarily the ICD-9 description. The primary reason for this is to not confuse the user by showing something different from what they originally selected in the search results.

Conclusion

The ongoing question of buy versus build should always be a question to present in any significant architecture. Time constraints, ease of implementation, flexibility, and maintainability were major factors in our decision-making process and eventually led to the selection of Health Language Inc. as a solid solution for Practice Fusion.

In the end, Practice Fusion has been able to provide our physician customers with a richer data set, multicode system support, and a Meaningful Use Stage 2 EHR certified feature in a transparent way that required near-zero modification to their existing user experience.

How providers moved from ICD-9 to SNOMED codes