OHDSI Home | Forums | Wiki | Github

How disease/diagnosis (ICD10) can transformed to a procedure record?

Please see, @Christian_Reich,

We’re developing CDM from EHR in Korea, and basically extract diagnosis records for condition_occurrence table.
And the diagnosis code (KCD) are based on ICD10 codes, so we’re partially using ICD10 to SNOMED relationships.

The issue is, some ICD10 codes have domain of procedure, observation and measurement, and I know we need to ETL those records to each domain tables the concept was mapped. Some diagnosis can be observation data I agree, but how they can be procedure or measurement?

I wonder if some patient have a ICD10 code record of “Z01.1, Examination of ears and hearing (domain: procedure)”, then it really means the patient got those procedures at the recorded date.

Because, it doesn’t in Korea. The same record of "Z01.1, Examination of ears and hearing’ means the doctor found that this patient visited the hospital to get those examination at the recorded date. And if he really got the examination, then new record of the examination should be created separately in other EHR table with the exam date information. Same for measurement. The codes don’t mean that something was measured.

If this is a problem that only happens in Korea, we will just try to map the source code to other condition domain concepts and set the concept_id as 0 if we couldn’t find appropriate concept.
If not, what should we do?

@Sooyeon_Cho:

Hm. Taking a hearing test doesn’t mean you have a condition. In fact, when I was a boy my mother took me to such a hearing test because I wouldn’t listen. Turned out I can hear the grass grow, so no condition there. :smile:

I realize that those ICD-10 codes are often duplicated by another “proper” procedure or measurement record in the source data, and you may end up with two of them in parallel, which has it’s own problems (see here for how THEMIS deals with them).

So, what do you think this code really means?

Hi,

Thank you @Christian_Reich, the link was not exactly the issue what I have, but very useful information.
What I was concerned is a little different, B person’s case below.
There have been some related issues from others, but below is the key point of it.

For some ICD (KCD) code of ‘AAA’, domain_id of procedure,

| person | diagnosis of ‘AAA’ | got AAA order of proc | ETL results in Procedure_occurrance |

| A… | yes… | yes… | 2 rows, duplicate, but proc was done |
| B… | yes… | no… | 1 rows, no data whether proc was done or not |
| C… | no… | yes… | 1 rows, no problem… |
| D… | no… | no… | 0 rows, no problem… |

B cases are really exist in Korean EHR, but after more discussion in our team, we concluded we can follow your guide.
Because B cases can bias the result of analyze, A cases also can be not true (EHR order data is not perfectly true), and we can distinguish them with data type_concept.

So, here is another question, sorry to bother you.

When the data form these code (ICD/KCD diagnosis…) goes to other domain table besides condition_occurrence, what the type_concept_id should be?

Candidate concepts I found,

  • to procedure: ‘42865906 condition procedure’, ‘38003622 Procedure recorded as diagnostic code’
  • to measurement: ‘patient reported value’
  • to observation: ‘44814721 Patient reported’

@Sooyeon_Cho:

The Type Concepts should denote where you got that information from in a non-database specific way, so folks can make a fair assessment of the relevance or confidence of the data. So, if the diagnosis/procedure was patient reported - pick a Type Concept like that. If it was recorded by the provider in an EHR - take that.

It’s not typical that current (not history of) procedures are recorded through patient reporting. That is more common for signs, symptoms and medication that is not initiated by the provider of the current visit.

t