OHDSI Home | Forums | Wiki | Github

New Comprehensive Hierarchy for Providers, Visits (and Place of Service, Specialty, Care Site)

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

And fixed the documentation.

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

@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:
image

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:

  • Conflation of semantic types
  • Poor coverage
  • Limited hierarchical relationships
  • Lack of polyhierarchical relationships
  • Difficulty in getting new concepts added to keep pace with needs of researchers

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:

  • provider_specialty_concept_id => new concept | Movement disorder neurology specialty (qualifier value) |
  • place_of_service_concept_id => new concept | Movement disorder clinic (environment) |
  • visit_concept_id / visit_detail_concept_id => new concept | Movement disorder services (qualifier value) |

@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

@piper:

This has been discussed a lot before. Looks like we forgot to drop place_of_service_concept_id from the CARE_SITE table. :frowning:

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:

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

t