OHDSI Home | Forums | Wiki | Github

Standard concept in visit domain for telephone encounters

Hi all -

We have a use case that requires us to load telephone encounters into the visit_occurrence table and distinguish these from telehealth encounters.

The concept id we are using for telephone encounter comes from SNOMED.
The concept is part of the Observation domain, not the Visit domain.

Could this be changed?


Hello, @Piper-Ranallo

I am afraid this should not be changed. We don’t use SNOMED concepts as standard visits. Currently accepted concepts could be found here (pretty sure you’ve already looked there).

I would suggest using source_concept_id field to distinguish between two source concepts (in your case telehealth and telephone) mapped to the same target (telehealth).

And the second option is using SNOMED Observation concept in Observation table to distinguish them.

1 Like

Thanks for the response.

Our initial approach was just what you suggested - use the standard concept_id for telehealth for both telephone and telehealth encounters and use the source_concept_id to distinguish between the two.

The collaborative we’re working with (multiple sites) feels strongly enough about using a discrete concept id to represent telephone visits that they have elected to use the concept id for telephone encounters in both visit tables (i.e., as visit_concept_id and visit_detail_concept_id) despite the concept not being standard in the visit domain.

Is there a reason we should discourage this?
Is there a reason for the Odyssey community to treat telephone encounters as observations rather than visits, and/or to not have a discrete concept for telephone encounters in the visit domain?

Appreciate any insight you can provide,

Well, this is against CDM convention, but off the top of my head, it should not break anything, but you need to be aware of this customization.

It is also possible to add telephone visit under telehealth visit with the help of recently published Community contribution · OHDSI/Vocabulary-v5.0 Wiki · GitHub

But is it necessary? I don’t think that this particular concept is really needed.
I would rather go with the custom option.

1 Like

But is it necessary? I don’t think that this particular concept is really needed.

Can you tell me more about why it may not be needed?
The consortium we’re working with seems to think it’s important.
However, we are all newish to OMOP and appreciate any lessons learned from more experienced OMOPers.


It is inevitable to lose data when you do your ETL. On the one hand, it is clearly bad, but on the other hand, it allows you to roll up to Standards and unite under one umbrella some clinical facts that are so generic in your data that could not be analyzed in any other way.

Getting back to your case. If you want to introduce one new concept (seems legit), why only this one? Let’s introduce laptop consultation, PC consultation, etc. - let’s build a comprehensive hierarchy. So, perfect is the enemy of good.

If this is important for you - go for it, but I would be against introducing this concept to everyone.

This is only my opinion, some people may disagree.


Thanks for the thoughtful responses.

Much appreciated,