OHDSI Home | Forums | Wiki | Github

Reused ICD9CM codes in ICD10CM

Vocabulary Users
#1

During my translation of ICD9CM and ICD10CM encounter based conditions, I ran across several codes that are both in the ICD9 and 10 code sets. Our source tables do not inform us of which code set is being used, other than local knowledge that everything is ICD9 or 10. From my preamble above, I am having to make some interesting logic to find the correct concept_id, which appears to be within a rounding error of 100%, at least for our internal data.

I am not asking for a fix, I am posting this as I would have saved hours on researching this if I could have found this here, or for that matter, anywhere that a search engine would have crawled to.

Here is the SQL that I am basing one of my bridge tables on:

SELECT ax.concept_code,
       c3.vocabulary_id AS icd9_vocab, c3.domain_id AS icd9_domain, c3.concept_name AS icd9_desc,
       c4.vocabulary_id AS icd10_vocab, c4.domain_id AS icd10_domain, c4.concept_name AS icd10_desc
FROM
(
  SELECT c1.concept_code FROM concept (NOLOCK) c1 WHERE c1.vocabulary_id = 'ICD9CM'
  INTERSECT
  SELECT c2.concept_code FROM concept (NOLOCK) c2 WHERE c2.vocabulary_id = 'ICD10CM'
)ax
INNER JOIN concept (NOLOCK) c3
 ON ax.concept_code = c3.concept_code AND c3.vocabulary_id = 'ICD9CM'
INNER JOIN concept (NOLOCK) c4
 ON ax.concept_code = c4.concept_code AND c4.vocabulary_id = 'ICD10CM'
ORDER BY ax.concept_code;
#2

Hello, @Mark

Thank you for sharing your experience with us. The community would truly benefit from it. What was your logic?

I would really suggest using dates to determine the right vocabulary, given the fact that ICD9 is much older than ICD10, but it is just a suggestion.

@MPhilofsky could you help with the best practices, please?

#3

Given: We have an AOU instance, not everyone’s records have been OMOP’ed.

Dates was how the old code was being done and as I expanded out the patient base, is where we ran into problems. I was not here in 2015, so I cannot comment on why some codes were not updated.

Our EHR has both a code and a code description, I do not know if this is common with other EHR’s so what I have may or may not work for others; I am building a bridge table, where ehr.code = bridge code and ehr.code_desc = bridge.code_desc and doing a LEFT OUTER JOIN with the EHR data with a COALEASCE(bridge.replacement_code, ehr.code) to pull data from the bridge table.

I have to display this in pseudo-SQL as I am not allowed to disclose our internal data structure (security policy); hopefully that is enough to help.

EDIT: our EHR’s code description does not match the concept table concept_name, is why I had to build a bridge table; The description is close enough for human translation though.

#4

Hello @Mark,

@zhuk is correct. It is best to use dates to determine if a source code is from ICD9CM or ICD10CM.

As an AOU partner, you’re in the US and have ICD9CM and ICD10CM codes in your EHR source data. On October 1, 2015, the US switched from using and billing with ICD9CM codes to using ICD10CM codes. So, you can match all ICD codes < Oct. 1, 2015 to vocabulary_id = ‘ICD9CM’ and all codes >= Oct. 1, 2015 to vocabulary_id = ‘ICD10CM’.

#5

I have verified that if I do this, I will be sending up incorrect data. This is an artifact of our EHR or the master tables it is pulling from; which I do not know.

#6

Do you want to show some examples of some incorrect data? I might be able to help you trouble shoot this. No need for PHI data elements, all we need to take a look are the source code, source description, and month/year. Also, what EHR system are you using?

And the publication of ICD10CM code set containing the same codes as ICD9CM was a very poor decision. I hope this doesn’t occur when the US moves to ICD11CM!

#7

There is nothing to troubleshoot, at least on my end. If I see a V code in 2012 that has description of ‘x’ and I see the same code in 2020 with the same description, there is nothing to do but build a bridge table or exclude all dual ICD set codes, one of the two. I cannot expose our data any more than that, I am sorry.

I did not start this thread looking for a solution, I started it as a datam, for others, that might run into this problem in the future; Perhaps I should have put this in the Implementers section instead.

#8

Mark:

To confine the problem a little bit:

  1. This is a US only problem, the WHO ICD9 had no V codes. They are really not even diagnoses, more like circumstances.
  2. The US Center for Medicaid and Medicare Services (CMS), and with it all private payers, stopped the use of ICD9CM in October 2015 for reimbursement claims. Not sure if any institution is still using it, because for EHR documentation purposes ICD9CM V codes are pretty useless. Is it possible that these are ICD10CM codes starting with V (which are proper ICD10), and the EHR wrongly adds the old descriptions? I would be very cautious with that.
  3. If the database has no way to distinguish them and uses the same field for either code and no extra flag for distinction, and you cannot think of any other heuristic, I would kick them out.
  4. I don’t see how OHDSI would you be able to help in any other way.
#9

That is a very valid concern, I will do farther investigation.

I would like to, but AOU does not want us dropping data out of the uploads. I agree, bad data is worse than no data, so I am attempting to go the extra mile to get said data correct. I will bring this up with AOU/MITRE.

Thanks to everyone for their feedback, I did not intend for this to become this major of a thread.

t