Mapping BI-RADS related terms to SNOMED CT

Vocabulary Users
1

Hey folks,

I am working on a project involving the OMOP common data model and I am attempting to map BI-RADS related terms such as Background Parenchymal Enhancement (BPE) to SNOMED CT terms.

Screenshot from 2023-10-05 12-07-52
Screenshot from 2023-10-05 12-07-52948×160 18.7 KB

However, I haven’t had any luck finding a corresponding term through Athena.

Does anyone have experience in this domain who could provide some guidance or pointers?

2

Hello @zkhan! Thanks for your question. Unfortunately, we don’t have such a concept at the moment. You can create a GitHub issue here, and we will consider adding it in the OMOP Extension during the next release.

In the meantime, you can create and use 2 bill+ standard concepts locally.

3

Please help us do so - check our Community contribution guidelines

1 Like
4

I work with data from echos and other medical devices that do not have a good concept mapping within SNOMED, LOINC, and other standard vocabularies. If you need to get your data into an OMOP database to start working with it and do not need necessarily to use OHDSI tools - one option is to go ahead and create a custom vocabulary to cover these unsupported concepts and then work through the standards group to get those data elements supported. I am taking this approach for some device data as well as covering data from pre-hospital patient care records from emergency medical services.

5

Thanks Maria, I will be creating an issue related to this. Could you please expand on usage of bill+ standard concepts?

6

That’s a fair point, what has been your experience / progress with getting these data elements supported?

7

You should create a custom vocabulary and populate all the necessary fields:
concept_id, concept_code, concept_name, concept_class_id, standard_concept, invalid_reason, domain_id, vocabulary_id.

Rules for populating:

  • Assign ‘concept_id’ values starting from 2,000,000,000.
  • Set ‘standard_concept’ to ‘S’ and leave ‘invalid_reason’ as NULL.
  • The ‘vocabulary_id’ should be the name of your custom vocabulary.
  • You can fill all the other fields in the way you need.

Map to these concepts in the same way you typically map to OMOP concepts. The usage remains the same.

8

@Maria_Rogozhkina,

There is an error in your above post. You state

However, concept_ids created by OHDSI users ALWAYS have standard_concept is NULL because these OHDSI user created concepts will be mapped to standard concept_ids!

9

@MPhilofsky It’s not that straightforward for Survey and other EAV data.

Does your proposal address this @MaximMoinat?

Linking to relevant topic.

10

Is that because it is using value_as_concept_id (which does not have a source_concept_id equivalent field)? Or is there some other complexity?

Indeed, the Themis issue addresses a lot of these conventions (but not the value concept issue).