OHDSI Home | Forums | Wiki | Github

Custom (local) terminology and preferred terms - experience? advice?

CDM Builders
,
#1

We have our own terminology/vocabulary that’s fairly extensive. We’re evaluating the best way to bring it into OMOP as a local vocabulary. Assuming we’ll bring it in as new concepts and map to standard concepts… does anyone have experience or advice to offer regarding “preferred terms” from our existing terminology?

My first instinct is to 1) create new concepts using the preferred name from our terminology for the new concept name, and 2) if the original concept name is different than the preferred name, then create a synonym to preserve the original name.

Is there a best practice or preference from anyone who’s done something like this?

#2

Hello-hello! While the Vocabulary team is working on the instructions on how to bring your vocabularies into the system and the templates to populate (stay tuned :)) there is a couple of details about your vocabulary that may help.

  • What is the vocabulary? Is it conditions or procedures or drugs or else?
  • Does it have internal structure (links/hierarchy) or is it just a collection of codes? Can you show a couple of examples? :slight_smile:

Regarding your specific questions: the names of the preferred terms (standard terms in the OHDSI world = those that have standard_concept = “S”) and your source terms do not have to match. The names have to be in English though.

Different names may imply that the mappings from your source terminology to the standard terms are not precise (not an exact match). If that’s the case, given a growing interest in annotating the relationships, it would also be good if you store the information about precision of your mappings (or how they were derived) somewhere.

1 Like
#3

Hi Anna!

Very interested in the templates to populate. Any chance of an early preview?

-S

1 Like
#4

Funny :slight_smile:

Actually, what can be used as a preview is the existing structure of CONCEPT and CONCEPT_RELATIONSHIP tables. In the former one you won’t populate the ids, but we pretty much want to know the rest of the fields :slight_smile:
In the latter you won’t know the ids again but will know your source codes and we want that along with the type of the relationship.

1 Like
#5

Hi Anna

In a lot of cases, the terms don’t “match” but they do have the same meaning. I REALLY like the idea of storing information about the precision of the match.

To answer your clarification questions: Our vocabulary is robust and covers about anything you’d find in a clinical setting. There is quite a bit of internal structure. Again, the full gamut. Ancestor/descendent, categorization, clustering, and probably things I don’t even know about yet. :blush:

I think I might have abbreviated my question too much, so I hope you’ll bear with a more verbose version of it.

We’re doing a pilot with a very limited scope just to get the mechanics down. We’re focusing on simply vital signs measurements. We want to only bring things in as we need them. We want to preserve our internal concept IDs as *_source_id. The idea is that as our usecases evolve we can take advantage of our additional structures. (This is probably a topic of its own.)

To illustrate my question as simply as possible: I’m bringing in a height measurement of a person. Our source record references a measurement concept from our vocabulary:

code: C9876 (our internal code)
name: Average Height
preferred name: Height Averaged
mapped to: LOINC 8308-9

We want our OMOP measurement record to reference a standard measurement concept.

concept_id: 3015514
concept_name: Body height --standing
vocabulary_id: LOINC
concept_code: 8308-9
standard_concept: S

My (maybe naive) approach would be to create a new concept in the OMOP vocab for our concept [C9876], and then map it to the standard concept [3015514] (we’d use the LOINC code to find the standard concept.)

Then the measurement record in OMOP would have:

measurement_concept_id: 3015514 (the “standard” concept)
measurement_source_concept_id: (our newly created concept representing the height measurement from our vocabulary)

Phew. If that’s a valid approach, I’d like to capture as much info as I can from our original concept. For example, the preferred name as a synonym? That was my original question, but it’s probably a deeper question. As we get more sophisticated with our usecases, should we capture other more robust elements of that concept (e.g. categorizations, ancestors, etc.) within the OMOP vocabulary? Are others doing similarly?

Hope that wasn’t TL;DR.

#6

Hello @jefmckenzie,

The Healthcare Systems Interest Group discussed custom, semantic mapping (mapping your local codes to standard concept_ids) on Monday. You can review the recording here.

1 Like
#7

Thanks Melanie! You’re doing great job over there :slight_smile:

So custom mappings on you side would be one option, a faster one, as it won’t involve dependency on the OHDSI release schedule and resources.

Incorporation in the OHDSI Vocabularies would be another one (not mutually exclusive). Of course, the more complex the structure of the source vocab is the harder it gets.

In terms of the names (thanks for the detailed explanation): I’m not sure what exactly the use case for preferred terms is but it’s up to you. The preferred name would be the concept_name and the other one would go into concept_synonym indeed. And the mappings would go into concept_relationship.

#8

Thank you both for the great responses! I’ll continue down the path that I’m on, and keep an eye out here for information on instructions and templates from the Vocabulary group. I’ll also check out the Health Systems Interest Group. Seems they might be solving problems similar to the ones I’m working on. Thanks again!

#9

Hello @aostropolets! We love it when an OHDSI guru peaks in our group :slight_smile:

What are some guidelines on what/when a vocabulary would be adopted/supported and brought into Athena and incorporated into the OHDSI supported Vocabularies? I know my local lab result vocab where positive is spelt “possitive” won’t make the cut, but what about regional drug vocabularies, proprietary interface terminologies and other local coding systems?

As you know, members of the HSIG do a LOT of custom mapping. How do we book you as a guest speaker for when the following is completed:

t