OHDSI Home | Forums | Wiki | Github

CDM v5.2 Release

General
#1

Hi Everyone,

Version 5.2 of the CDM is now available on github. It is backwards compatible with v5.0.1 and includes the following changes:

  • Adds the field VERBATIM_END_DATE to DRUG_EXPOSURE and makes DRUG_EXPOSURE_END_DATE a required field

  • Removes EFFECTIVE_DRUG_DOSE and DOSE_UNIT_CONCEPT_ID from DRUG_EXPOSURE

  • Adds the field BOX_SIZE to DRUG_STRENGTH

  • Adds the following fields to VISIT_OCCURRENCE:

    • ADMITTING_SOURCE_CONCEPT_ID
    • ADMITTING_SOURCE_VALUE
    • DISCHARGE_TO_CONCEPT_ID
    • DISCHARGE_TO_SOURCE_VALUE
    • PRECEDING_VISIT_OCCURRENCE_ID

  • Adds the following fields to CONDITION_OCCURRENCE:

    • CONDITION_STATUS_CONCEPT_ID
    • CONDITION_STATUS_SOURCE_VALUE

  • Adds the following fields to COST:

    • DRG_CONCEPT_ID
    • DRG_SOURCE_VALUE

  • Adds the NOTE_NLP table and the following fields to NOTE:

    • NOTE_CLASS_CONCEPT_ID
    • NOTE_TITLE
    • ENCODING_CONCEPT_ID
    • LANGUAGE_CONCEPT_ID
OMOP-CDM v5.2 release
#2

What is the meaning of the condition_status_concept_id and concept_status_source_value as I am currently using the CDM and want to be able to update my ETL accordingly?

#3

Hi @mimictoomopplease CONDITION_STATUS is basically a way to determine admitting diagnosis, etc. You can find more information here. I also wrote some release notes detailing each change with links to each proposal.

Clair

#4

@clairblacketer Also as a quick question. When utilizing the condition occurrence table, if a source concept maps to two or more standard concepts, how can I express that in the condition occurrence table as the condition_concept_id field only takes one argument?

#5

@mimictoomopplease typically if a source_concept_id maps to two or more standard concepts we retain those mappings in the condition_occurrence table so you would see two rows for the given source value, each with a different condition_concept_id.

Tagging @ericaVoss

#6

@clairblacketer is correct.

For example, ICD10CM S91.245-Puncture wound with foreign body of left lesser toe(s) with damage to nail maps to th following standard standard concepts:

  • 4153263-Puncture wound of toe
  • 4185018-Foreign body of skin of toe

Any time you saw S91.245 in an ICD field, it should write two records to the CONDITION_OCCURRENCE table, one for each concept list above, both with SOURCE_VALUE as S91.245.

If you are interested in how I got from that source code to the standard CONCEPT_ID, here is the query I used:

WITH CTE_VOCAB_MAP AS (
       SELECT c.concept_code AS SOURCE_CODE, c.concept_id AS SOURCE_CONCEPT_ID, c.concept_name AS SOURCE_CODE_DESCRIPTION, c.vocabulary_id AS SOURCE_VOCABULARY_ID, 
                           c.domain_id AS SOURCE_DOMAIN_ID, c.CONCEPT_CLASS_ID AS SOURCE_CONCEPT_CLASS_ID, 
                                                   c.VALID_START_DATE AS SOURCE_VALID_START_DATE, c.VALID_END_DATE AS SOURCE_VALID_END_DATE, c.INVALID_REASON AS SOURCE_INVALID_REASON, 
                           c1.concept_id AS TARGET_CONCEPT_ID, c1.concept_name AS TARGET_CONCEPT_NAME, c1.VOCABULARY_ID AS TARGET_VOCABUALRY_ID, c1.domain_id AS TARGET_DOMAIN_ID, c1.concept_class_id AS TARGET_CONCEPT_CLASS_ID, 
                           c1.INVALID_REASON AS TARGET_INVALID_REASON, c1.standard_concept AS TARGET_STANDARD_CONCEPT
       FROM CONCEPT C
             JOIN CONCEPT_RELATIONSHIP CR
                        ON C.CONCEPT_ID = CR.CONCEPT_ID_1
                        AND CR.invalid_reason IS NULL
                        AND cr.relationship_id = 'Maps To'
              JOIN CONCEPT C1
                        ON CR.CONCEPT_ID_2 = C1.CONCEPT_ID
                        AND C1.INVALID_REASON IS NULL
       UNION
       SELECT source_code, SOURCE_CONCEPT_ID, SOURCE_CODE_DESCRIPTION, source_vocabulary_id, c1.domain_id AS SOURCE_DOMAIN_ID, c2.CONCEPT_CLASS_ID AS SOURCE_CONCEPT_CLASS_ID,
                                        c1.VALID_START_DATE AS SOURCE_VALID_START_DATE, c1.VALID_END_DATE AS SOURCE_VALID_END_DATE, 
                     stcm.INVALID_REASON AS SOURCE_INVALID_REASON,target_concept_id, c2.CONCEPT_NAME AS TARGET_CONCEPT_NAME, target_vocabulary_id, c2.domain_id AS TARGET_DOMAIN_ID, c2.concept_class_id AS TARGET_CONCEPT_CLASS_ID, 
                     c2.INVALID_REASON AS TARGET_INVALID_REASON, c2.standard_concept AS TARGET_STANDARD_CONCEPT
       FROM source_to_concept_map stcm
              LEFT OUTER JOIN CONCEPT c1
                     ON c1.concept_id = stcm.source_concept_id
              LEFT OUTER JOIN CONCEPT c2
                     ON c2.CONCEPT_ID = stcm.target_concept_id
       WHERE stcm.INVALID_REASON IS NULL
)
SELECT *
FROM CTE_VOCAB_MAP
WHERE SOURCE_CODE = 'S91.245'

Run on Vocab 20170503.

#7

I think your query will miss when a concept has been updated
(invalid_reason = ‘U’), unless you populated source_to_concept_map with
updated concepts.

1 Like
#8

@DTorok You mean for CONCEPT_RELATIONSHIP.INVALID_REASON? In 20170503 it is always NULL.

Or do you mean the target CONCEPT.INVALID_REASON?

Or do you mean on the SOURCE_TO_CONCEPT_MAP.INVALID_REASON, we force that to be NULL on our side.

#9

Concept.invalid_reason

E.g. HCPCS J7130, updated, ‘Concept replaced by’ J7131. So that starting
with ‘J7130’, find that it is replaced by HCPCS J7131 and then find the
‘Maps to’ relationship for HCPCS J7131 and you end up with to RxNorm
concept 968037 (Sodium Chloride 1000 MG). At least that is my
understanding.

#10

@DTorok - woah are you saying that we get a source code from raw data but then the Vocab tells us that source code shouldn’t be X it should be Y, and then based on Y map to a standard concept? We aren’t doing anything like that. We take the source data as it is and map it to standard terminologies.

Am I still missing your comment?

Additionally this query is just mapping a source to standard, there is a different one to map a source code to a source concept.

#11

I don’t know enough about when, why or how often a concept may be
‘updated’. But for the example given above, I would set the drug_concept_id
to 968037 (Sodium Chloride 1000 MG), where the code you presented would set
it to zero. I don’t think it is a big deal, just something I noticed.

#12

@DTorok

None of this should happen. I have the team take a look. If there is an update, the Maps to should go from the updated right to the new Standard Concept. Unless it is missing entirely, then we are falling behind.

#13

Interesting. Because I assumed the code needs to first lookup the ‘Concept
replaced by’ relationship when the invalid reason is ‘U’, I never checked
the ‘Maps to’ relationship for the updated concept.

Here is what I found for source code '‘J7130’.

  • The concept id is 2718667 and invalid reason is ‘U’
  • The concept’s ‘Concept replaced by’ relationship points to concept id
    40664792, ‘J7131’.
  • *Both *J7130 and J7131 have ‘Maps to’ relationships to concept 968037,
    and RxNorm code for ‘Sodium Chloride 1000 MG’

This indicates that the step I advocated of first finding the ‘Concept
replaced by’ is unnecessary.

I have not checked other examples, but for this case the take-away is that
in doing the ETL the code should look up the standard concept using the
‘Maps to’ relationship when the invalid_reason is NULL or ‘U’.

Now the question is, what should the ETL do when the source concept id
invalid reason is ‘D’? Should the ETL exclude a concept where the invalid
reason is ‘D’, or should the ETL just trust the ‘Maps to’ relationship and
ignore the invalid_reason of the source concept when looking for the
standard concept?

#14

From my understanding, the original code (J7130) should be mapped to the corresponding standard concept regardless it was obsoleted or replaced by another code. The question is whether the new code ends up the same standard code as the old one, and the good news is YES. I checked all replaced codes, and they all map to the same standard concept as the old ones.

#15

@abedtash_hamed:

You are totally correct.

#16

Hello @clairblacketer,
thank you very much for the notification about the new version release.

I would appreciate if you could provide the information on the following questions:

  1. May we consider the version 5.2 as stable and start converting to it? Or new updating may come soon? I saw ongoing discussions on the topic of building visit_occurrence and building the team for solving the most common issues. What do you think about it?
  2. The tables on Wiki document are not updated to v. 5.2. When can we expect an update there?

Thank you,
Tatiana

#17

Hi @TBanokina,

We haven’t yet decided when the next release will be, though I do know that it will include a new table called VISIT_DETAIL. It is up to you whether you want to move to version 5.2 but here are my thoughts:

  • If you are still on version 4, go ahead and move to 5.2
  • If you are on version 5 or above, take a look at the release notes for 5.2 and, if the additions are useful to you, move to 5.2
  • If the VISIT_DETAIL table is of more interest to you than the additions made to 5.2, I would wait for the next release. Version 5.2 is backwards compatible with version 5.0.1. It also works well with version 5 unless you are doing anything with cost as we moved to the single cost table in 5.0.1

The documentation on the OHDSI wiki is outdated, you are correct. It has moved to github to allow for better version control. I have added some notes to the OHDSI wiki indicating this but I will make it more clear.

Thanks,
Clair

#18

@clairblacketer Thank you for your quick response. I am looking forward for the release with VISIT_DETAIL table.

t