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
@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:
- 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
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
Nothing wrong with SNOMED. We like SNOMED.
Disadvantages are:
- Folks don’t have the data. The current specialties are derived from the codes that are used in US and UK-based systems.
- It’s a lot of work to replace and map the existing to the SNOMED.
To push us over the hoop would require a strong use case that is not possible with the current system.
These are not specialties in the sense of a medical specialty. These are Visit concepts in the sense we want them to be: defined by what service is provided how, is the patient stationary in a bed or only visiting. So, all good. We have no disagreement.
Oh, we are infinitely faster. We do NOT have to wait for any of those source vocabularies to make a change. We just used them for convenience.
So, instead of doing a gigantic surgery of ripping out all the existing Visits and replacing them with SNOMED, including the mapping, should we just add the ones you need?
I see what you’re saying, @Christian_Reich. Most folks are natively encoding data using values from one or more of the vocabularies designed for adminstrative use cases (NUCC, Medicare Specialty, Medicare Place of Service, UB04 Typ bill, etc.). Drawing OMOP standard concepts from these vocabularies reduces the mapping burden for OMOP CDM builders.
And now I understand why attributes of care sites (enviornments) and visits (services) were merged into a single concept and made an attribute of visit. [Edit (added): The standard vocabularies conflate two discrete concepts: service line/specialty and physical environment; users are forced to assume that both mean “service line/specialty”] We struggled with this too!
On the other hand, the physical environments in which healthcare services are delivered is a potentially significant source of variation in outcomes. There’s a valid use case for capturing this as a discrete data element.
Agree - these are not specialties. However, these are not visit concepts either. These are healthcare environments. A visit for any given service (specialty or service line) can occur in any number of environments. The physical environment iteself may be an important variable in healthcare outcomes.
@Christian_Reich, I know you are! 
And it’s an awesome way to get what we need immediately while we wait for the appropriate SDO add the missing concept. 
(If we need it in OMOP, someone else out there is going to need it too!).
Not proposing major surgery 
, proposing further investigation to identify the least risky approach to ehancing OMOP in this area to achieve our objectives.
How about a conservative near-term solution and consideration of the need for a less conservative longer-term solution?
Near term:
-
Commit to mimimal disruption to current-state
-
Add missing standard concepts as part of proprietary OMOP vocabulary
-
Identify SNOMED concepts not yet mapped to an OMOP standard concept and perform the mapping
(@Christian_Reich regardling the last two bullet points, would we make the SNOMED concept the OMOP standard concept for these? Or do the pre-designated OMOP standard vocabularies for a given domain preclude vocabularies other than OMOP for missing concepts in the domain?)
Longer term solution
-
Discuss the value proposition of maintaining place_of_service_concept_id as an attribute with explicit guidance to populate this with concepts for physical environments (not services provided in the environment)
-
Discuss pros and cons of using SNOMED | Environment (environment) | hierarchy as source of OMOP standard concepts for place_of_service_concept_id
-
Discuss pros and cons of using the SNOMED | Healthcare services (qualifier value) | and/or | Clinical specialty (qualifier value) | hierarchy as source of OMOP standard concepts for visit_concept_id
In preparation for such discussions:
-
I will pull together some empirical findings in support of the value proposition of the changes being recommended here
-
Anything else that would be helpful to do in preparation for these discussions?
How does this sound?
Piper
Not quite. Specialty is a degree or qualification of a provider (a flesh and blood provider), and the Domain is Provider. Visit is indeed a combination of a bunch of attributes:
- Who is coming to whom
- Level of service
- Physical environment
- Organizational structure
But it is a configuration in which healthcare is provided. The domain is Visit.
Why is it Visit, and not Care Site? Because the Care Site is a physical structure, but it can allow different types of Visits in the same Care Site. Also, the same Visit can host providers with a variety of specialties.
I realize Visit is confusing to people, because they are not used to describing the meaning. But the most common Visits (inpatient hospital and outpatient) are exactly that.
We could open that box again, but I don’t see a different outcome. First, we have them all in Visit, and second, the same Care Site can have different places of service: typical examples are inpatient and outpatient hospital, or non-residential substance abuse treatment facilities and non-residential opioid treatment facility. It depends on the Visit what happens to the patient.
We could, too, but the fact that they split them into two is already problematic. For example, gynecology and clinical oncology are clinical specialties, gynecological oncology is a healthcare service, and oncology does not exist at all. You will have a hard time convincing anybody. 
But let’s see.
We will.
This is part of a larger problem we have: “Destandardizing” duplicate concepts (mostly in SNOMED) where we have picked a standard concept. Or where two concepts of identical meaning are standard. This will be a big surgery.
Yes, provider specialty is pretty straightforward.
VISIT seems to boil down to the healthcare services being provided.
Physical environment is a feature of the CARE_SITE. The same healthcare services can be provided in any number of care sites. The environment may impact the quality of care. Why not capture this attribute in CARE_SITE?
Yes - there are care sites within care sites.
- Organizations that explicitly define the care sites within the larger care site would have the option to map to the more granular environment concept
- Organizations that don’t define the component care sites would still be able to map to a less granular environment type (e.g., Hospital)
Yes, the visit type concept describes what healthcare services are provided. I think we’re saying the same thing.
Yes. My error. | Clinical specialty (qualifie value) | concepts are not appropriate for defining a visit. These are attributes of:
- A healthcare worker, i.e., a provider
- A department, group, or team, i.e., a physical or logical entity representing an organized collection of resources. (In Epic, both providers and departments can be assigned a specialty]
| Healthcare services (qualifier) | concepts represent the idea we seem be capturing when defining VISIT. @Christian_Reich do you agree?
Yes, there are gaps that need filling. Not a problem.
In my experience, SNOMED has been more responsive to requests than CMS and other beauracracies that manage adminstative code sets. (Fully disclosure, I have only ever asked SNOMED to add or modify concepts, so CMS might be more agile than I’m assuming)
@Christian_Reich I love a challenge
piper