I am confused around the hierarchy…based on what you are saying, VISIT Visit is the highest level with VISIT Place of Service being under that (Outpatient Visit - Urgent Care Place of Service) (XYZ Visit - Telehealth Place of Service) is that correct? We are seeing both Telehealth and UC Facility as Place of Service, and UC is mapping to Office Visit (not Outpatient) which would be the top level based on what we are seeing. I’m looking at Athena though, and it’s a bit confusing. Is there a better resource?
I also need a little clarification 
And the VISIT OCCURRENCE conventions need clarification
We went from 5 standard visit concepts (IP, OP, ER, OP>IP, Long Term Care) where domain_id = ‘visit’ to 12 standards where domain_id = ‘visit’ and concept_class_id = ‘visit’ (new convention which adds concept_class_id to mapping requirement & needs to be added to the conventions, along with the fact that there are now more than 5 standard visit_concept_ids). In the 12 standards we now have visits that folks needed (Laboratory, Pharmacy) and visits that don’t make much sense: ‘Office Visit’ isn’t that an Outpatient Visit? And ‘Intensive Care’ is definitely an Inpatient Visit. Shouldn’t Office Visit & Intensive Care be children of their respective parents?
That’s why we started the post.
Yes, Ma’am. It’s parent is 9202 “Outpatient Visit”.
Correct. And so it is. The parent is 8717 “Inpatient Hospital”, and the parent of that is 9201 “Inpatient Visit”.
Neither one is part of the 12 top concepts. See my initial posting.
Not quite. “Place of Service” is no longer a domain. It is a vocabulary in the Visit domain. So is “NUCC” and “CMS Specialty”.
Not quite. There is no top concept called “Visit”. The top concepts are listed in the initial posting (scroll all the way up).
As Visit domain concepts…
Correct…
No. Office Visit itself has the parent 9202 “Outpatient Visit”. It’s iterative, hierarchical. You have to go up until you find no parent. Then you reached the top.
It’s not there, yet. We are rolling it out as we speak, and then you can look at it in Athena. (That may be the reason for your confusion, and @MPhilofsky’s confusion). Use the Google Doc listed above.
Correct, this is the reason for my confusion.
To sum up the recent discussion:
-
Athena has new standard visit concepts, some are NOT correct. (i.e. Office Visit & Intensive Care are standard concept_ids in Athena today, but will not be once the Visit domain has been refreshed by the Vocabulary team)
-
@Christian_Reich’s Google spreadsheet & original post list out the concept_ids to use for visit_concept_id. These include: inpatient, outpatient, ER, ER to inpatient, Non-hospital institutional visit (previously knows as ‘Long Term Care’), Laboratory Visit, Telehealth Visit, Pharmacy Visit, Home Visit, Transportation Visit, Rehabilitation Visit and Case Management Visit. All other visits will be source codes & will map to non-standard visit_source_concept_ids
-
The Vocabulary team will create parent-child/is-a relationships in the CONCEPT RELATIONSHIP & CONCEPT ANCESTOR table.
All good now. Check it out.
NOOOOOO!!! They are all there, standard and happy. But:
- They now roll up in the hierarchy to the top 12
- They are deduped, so if CMS Place of Service and NUCC have the same concept one of them became standard, and the other one become source, with a Maps to relationship. Like everywhere else.
All there. I think it works, but you guys need to make it fly.
Thanks for everyone’s work on this. It is very helpful. In using this hierarchy I have a couple questions. It looks like the “Telehealth” place of service code (concept_id = 5083) does not roll up into a visit type. Is this because telehealth encounters are not considered visits since they do not involve a patient going to a care site?
Another issue is the “Other Place of Service” code (concept_id = 8844) which seems to be used heavily. It has no standard concept. Maybe this is an ETL question but I’m wondering how people handle this code when creating visits.
Correct. It’s a “top dog”. Like Inpatient and Outpatient.
It does. It’s concept_id=0. So-called Flavor of Null. We don’t know what it is.
1 Like
Thanks @Christian_Reich. So would you create a record for a telehealth encounter in the visit_occurrence table and if so what would the visit_concept_id be? According to the CDM documentation the visit_concept_id must be in the visit vocabulary. Would it be incorrect to put the Telehealth concept_id (5083) in the visit_concept_id field?
Almost. It must be in the Visit Domain. So, 5083 “Telehealth” is just fine.
1 Like
I have another question and I think it belongs on this thread. Suppose I am creating a CARE_SITE record for a hospital with an associated taxonomy code from the NUCC vocabulary of 282N00000X (General Acute Care Hospital). What should go in the place_of_service_concept_id field? Does place_of_service_concept_id need to be a standard concept in the place_of_service domain?
General Acute Care Hospital is a standard concept which rolls up to Inpatient Hospital but both are in the visit domain so I’m not sure if it they belong in the CARE_SITE.place_of_service_concept_id field.
Oh. You found an lapse. The VISIT_OCCURRENCE table defines the care constellation, not the CARE_SITE table. In other words - a Care Site is not limited to a single way the care is provided. The same Care Site can have an office and an ambulatory surgery in the same instance. Put an issue in. Thanks, @Adam_Black
I’m not sure removing place of service from the care site table makes sense. Without it the table is just a name tied to a location. It seems natural that we would want some classification of care sites that would differentiate between an acute care hospital, a walk in clinic, a private practice, and a long term care facility for example. I guess you are saying that information should be represented in the visit_occurance table. Don’t we want some classification of different types of care_sites?
Correct. You can use it as a covariate for all sorts of purposes, but in itself it has no meaning.
You are absolutely right. It does feel natural, and that is why people inevitably gravitate to trying modeling it, over and over again. But after some lengthy debate we realized it is impossible, or very hard. Look: The way those sites organize themselves is completely local. An outpatient clinic might have a surgery attached. But not every patient is a surgical patient. It can also have a lab. Now what? Is it an outpatient office, surgery or lab? All three? What if the lab only consists of a couple urine sticks and a microscope on the desk of the doctor. Still a lab?
This is impossible to nail. The only chance to nail it is in the Visit. Each visit is pretty clear what happened. If you really really need that place_of_service (which outside the US is a crazy term anyway) then take all the Visits that happen in that Care Site and infer it from the visit_concept_id.
Makes sense?
Yes that makes sense. Thanks for the explanation.
@Christian_Reich is there a simple way to find the “top dogs” of the visit_hierarchy? Changing the concept_class to something like ‘top level visit’ will make it much easier to roll up the visit concepts using Concept_ancestor. Like getting ingredients for drugs is easy because you look for ancestors where the concept_class = ‘Ingredient’.
select * from concept
left join concept_ancestor on concept_id=descendant_concept_id and ancestor_concept_id!=descendant_concept_id
where domain_id='Visit' and standard_concept='S' and ancestor_concept_id is null
Something like that. Concepts that have no other ancestor than themselves.
A concept_class_id “Top dog” would do the same trick, unless we want to introduce some other meaningful Visit characterization. But nothing comes to mind.
1 Like
Sorry for the belated, dumb question but how does all this affect the Provider.specialty_concept_id field? Is that field staying around in 5.40? If so, will the 5.3.1 guidance still apply to it:
https://ohdsi.github.io/CommonDataModel/cdm531.html#PROVIDER
That vocabulary standard entries with the domain_id = Provider belong in PROVIDER.specialty_concept_id. There is a lot of talk in this thread about a provider_concept_id field, which I am not familiar with.
The provider.specialty_concept_id is in CDM v5.4 and the v5.3.1 guidance is applicable.
1 Like