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?
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.
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]
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)
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!).
, proposing further investigation to identify the least risky approach to ehancing OMOP in this area to achieve our objectives.
But let’s see.