| OHDSI Home | Forums | Wiki | Github |
All good now. Check it out.
NOOOOOO!!! They are all there, standard and happy. But:
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.
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.
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.
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.
@Christian_Reich et al -
Is there a document summarizing final community decisions regarding specialty - or is this still a work in progress?
In our second iteration of ETL development, we are focusing on encoding data locally, and using CONCEPT_RELATIONSHIP to retreive OMOP standard concept id. In the first iteration, we mapped directly to OMOP standard concept_ids.
We are doing a deep dive into specialty in all its forms - as a concept used to futher describe a provider, a care site, and a visit. Iām inclinded to want to capture the richness of the data as it exists in the source data to support analytics use cases, and am feeling less than satisified with the existing vocabularies.
Iām inclined to encode the data locally using a vocabulary thatās better suited to analytics use cases (to complement the encoding done using vocabularies for billing and other administrative use cases) such as SNOMED.
However, I see that none of the SNOMED concepts are mapped to the OMOP standard concept ids so we cannot use the CONCEPT_RELATIONSHIP to get the OMOP standard concept. We would also lose a fair amount of information in the mapping. Is there more history here? Was SNOMED considered as an option for the OMOP standard concept_idā¦
Thanks in advance for any insightā¦
Piper
This is the guidance from the CDMv5.4 documentation in https://github.com/OHDSI/CommonDataModel
Thie specialty_concept_id either represents the most common specialty that occurs in the data or the most specific concept that represents all specialties listed, should the provider have more than one. This includes physician specialties such as internal medicine, emergency medicine, etc. and allied health professionals such as nurses, midwives, and pharmacists. If a Provider has more than one Specialty, there are two options: 1. Choose a concept_id which is a common ancestor to the multiple specialties, or, 2. Choose the specialty that occurs most often for the provider. Concepts in this field should be Standard with a domain of Provider. Accepted Concepts.
Thanks @DTorok.
We followed this guidance when building our ETLs, but itās clear weāre losing a lot of valuable information as we move from local concepts to OMOP standard concepts.
Hereās how weāre thinking about the flavors of āspecialtyā for each of the tables that use these concepts:
The existing vocabularies used for these concepts (NUCC, ABMS, Medicare Specialty, UB 04, CMS POS, etc.) seem well suited for the adminstrative use cases for which they were desgined, but no so much for analytics use cases (i.e., encoding and using data in an OMOP CDM).
These vocabularies are problematic for the following reasons:
The discussion started by Dr. Wu here strikes me as good example of where requesting a couple of new SNOMED concepts for use in OMOP might address some of the problems identified by these researchers:
@Christian_Reich - any historical discussions about potential for SNOMED as standard vocabulary? What are yours (and other folksā) thoughts about exploring this more rigorously?
Best,
Piper
This has been discussed a lot before. Looks like we forgot to drop place_of_service_concept_id from the CARE_SITE table. 
Can be added as a child of Neurology.
Care sites no longer have a specialty. This is impossible to standardize. Only providers do, since they are getting certified for it.
How is this service different from existing ambulatory or hospital-based services?
Yes, agree.
What are your thoughts about using concepts in SNOMED hierarchy 394658006 | Clinical specialty (qualifier value) | as OMOP standard concepts for provider specialty?
Advantages are:
Ability to analyze data at varying levels of granularity (SNOMED has more robust hierarchical relationships than existing vocabularies from which standard concepts are drawn)
Ability to get new concepts added relatively quickly (SNOMED seems to be more agile than vendors of the other source vocabularies)
Agree itās hard. Agree we will sometimes (often?) end up using a high level concept that is redundant with services provided (attribute of visit). Nonetheless, I think itās important to specify the care site with more granular concepts when appropriate. Hereās why:
Clinical care is increasingly being provided in a highly specilaized settings (e.g., specially designed psychiatric units for assessing folks in mental health crisis, specialty LGBTQ addiction treatment centers).
More granular concepts for clinical settings supports the important Use Case of assessing outcomes (ROI) when care is delived in these kinds of specialized environments.
Concepts in SNOMED hierarchy 43741000 | Site of care (environment) | may be a a good source for OMOP standard concepts. Our organization is finding good coverage here, and SNOMED has been super responsive to our requests for new concepts.
Presumably, those sfaffing specialty service lines have specialized training. An ambulatory general pediatric practice may be staffed only by genreal pediatric providers, or it may have dedicated service lines staffed by specialized providers (e.g., a mental health service line staffed by a mix of psychologists, pediatricians, and APRNs with specialized training in mental health). Or an ambulaltory neurological clinical with a specialized movement disorder service line, staffed by a mix of neurologists and APRNs with specialized training in movement disorders).
The Use Case for capturing this as a discrete concept is to assess whether diagnoses made and procedures performed by a specialized team result in better outcomes that those made by a single general team of healthcare professionals staffing the site.
Piper