OHDSI Home | Forums | Wiki | Github

Care sites and specialty, specialty code clean-up

Care sites and specialty has been discussed many times. Excerpts of relevant discussions are below. I would like to propose that we add care_site_specialty_concept_id to care_site table.

Please advise.


I am getting this strong attic feeling again. We are putting specialties all over the place. What are the use cases? What kind of reports do you want to pull? We know that care sites have declared specialties, only to have providers deviate from it, and we know providers have specialties, only for them to list many. Sometimes so many that it is not humanly possible.

Why do we need this and for what? Can you enlighten me?

Friends: And especially those who have a strong feeling how claims and EMR data should be treated, namely @jenniferduryea, @Gowtham_Rao, @bailey:

As part of the Themis 4 job, the vocab team and I went through the vocabularies Specialty (CMS Specialty, really), ABMS, NUCC and HES Specialty. We find a lot of different concepts tossed together, some of it because the CMS doesn’t distinguish between individual providers and institutional providers. But we do: we have the PROVIDER and CARE_SITE tables. We therefore propose to clean things up and create four new Domains:

  1. Specialty: These are medical specialties. The kind of thing you can specialize as a physician, or that institutions (wards, department) organize their work around. Such as “Surgery”, “Internal Medicine”, “Radiology”. Everything else like Prosthetics, Accupuncture, Physical Therapy and all sorts of other Therapies would get the domain Service (see below). These specialties would be used in the PROVIDER and CARE_SITE (new field needed here, @bailey will be happy)
  2. Provider: These are individual providers: Physicians, Nurses, Dentists. Therapists and all sorts of other personnel that charges the CMS for services are NOT providers according to this logic. We might add a new field in the PROVIDER table: provider_concept_id.
  3. Care Site:: These are types of insitutions. Hospitals, clinics, offices, where healthcare is provided. Not agencies or ambulance services. In the CARE_SITE table, we’d have to rename the place_of_service_concept_id to care_site_id, making it consistent with everything else.
  4. Service:: This is the “garbage can” for all sorts of things that are relevant to healthcare, but none of the other three domains above. They would go into the OBSERVATION table.

The domain “Place of Service” is ambiguous. It is now the domain “Care Site”.

Again, the vocabularies are all over the place with mixing these things together. We are therefore proposing splitting them apart (like we do with HCPCS, CPT4, and to a lesser degree with the ICDs), and assigning our domains. We also want to remove duplicates and create a hierarchy, so you can rely on vocabulary to tell you that Hepatology is a kind of Gastroenterology is a kind of Internal Medicine. And we pull away the standard_concept=‘S’ from the silly flavors of NULL.

Take a look and complain or agree: https://docs.google.com/spreadsheets/d/1A4OFGoJtRCz-G5qju-TrR5UDFX7coXwuRo7Yw5KSslo/edit#gid=0.

1 Like

Good to see this gaining some traction! A few questions/complaints/comments for you, @Christian_Reich

Looking at line 5 on the spreadsheet, I see Parent1id (concept_id = 38004207) and Parent2id (concept_id = 38004230). Is parent1id a parent to parent2id? Or does the concept_id for line 5 have 2 parents?

Are Acupuncture offices and Physical Therapy clinics not institutions?

What do we do with these folks that produce Measurements and Observations and such? And, again, how does the layperson know the difference?

care_site_concept_id? Great for those of us that lack the Place of Service code system in their source data.

Are the 4 new domains also 4 tables? Who/what lives where?


Yeah, I could have given some explanations.

  • Parent 1, 2 and 3 are parallel. It’s just how you can do it in Excel.
  • Acupuncturists and physical therapy: According to this definition no. There are no such wards. Currently they cannot create visits. We have no use cases. But: This is not the scripture. We can change it. Give me use cases, and we fix.
  • Folks that produce Measurements and Observations: They are in Observation as service.
  • Laypersons are not use cases. Plus, there aren’t any of those in OHDSI. Everybody has to read the manual. If you are planning to build a tool for consumers the UI will have to do a lot of translation anyway. But that would be a use case I’d entertain.

No. The domains live in the DOMAIN table, and the concepts in the CONCEPT table. The data live in the CARE_SITE, PROVIDER and OBSERVATION tables.

Thank you @Christian_Reich for this fantastic work. This is hardwork, because many of these codes maybe considered ambiguous. I did some spot checks and most looked good.

Place of service vocabulary: this vocabulary, as used in US adm. Health claims, causes confusion. We recently changed it to domain_id = ‘Visit’. Does this proposal impact that?


I know we did. But since the new Place of Service is now something that characterizes the organization depicted in СARE_SITE - should we not call it that way? And leave the VISIT with the 5 big ones?

Yes - but it should not. If you look at the claim forms, place of service is an attribute of the visit not the attribute of the care_site. So, the place_of_service should be on the visit* table, not the care_site table.

No :smile:

Referencing prior discussions on this topic

There has been a lot of discussion around this topic to keep up with! :slight_smile:

At present, I’m most interested in ambulatory surgeries, so I’ll use it to see if I understand things…

@Christian_Reich based on your google sheet Ambulatory Surgical Center (8883) is from the Place of Service vocabulary and is now also part of the Visit domain. If that’s the case, does it mean that the visit_concept_id can be 8883?

I would agree with @Gowtham_Rao as being an attribute of a visit at least for ambulatory surgery, but i don’t know if 8883 fully represents ambulatory surgeries at our institution. we’ve only recently built a true ambulatory surgical center. Prior we have been doing amb surgs for years within our inpatient hospital, but just discharging within 24 hrs. For this reason, we have a separate visit category for ambulatory surgery within our clinical systems. I guess for analytic purposes we could just say it’s an ambulatory surgical center…

@Gowtham_Rao, the mapping of 8883 to 9202 in your document wouldn’t help us since we would still want to know if a procedure was performed in an OR vs a clinic, but I guess you are suggesting an additional field to the visit table?

@cukarthik place of service vocabulary is already in Visit domain and may be used as visit_concept_id. The mapping already exists. Please see here http://athena.ohdsi.org/search-terms/terms/8883

No changes to visit table being proposed.

Thank you for sharing this use case. We can handle these either thru ETL conventions (Themis) or thru study criteria rules (Atlas cohort criteria). I think the later is safer and protects the provenance of the data to the source.

Or just leave it as Ambulatory Surgical Center. It’s doesn’t seem to have any great impact, as medical care should be the same regardless of whether it’s a separate building or a part of an inpatient hospital.

@Christian_Reich I’m helping Ray Chen populate some of the Columbia OHDSI provider tables. Am I correct in reading that NUCC is the most comprehensive/most widely used vocabulary for provider_id? We are trying to figure out which vocabulary to use.

Also do you happen to know how recently the Athena Vocabulary has been updated? The ids am using from columbia dont match those in Athena but ours does have fewer so it very likely just needs to be updated. (It seems to be all of the NUCC specialties that are six digits and begin in a 9)

The Provider Specialty vocabulary you use is typically determined by what you have in your source data. If you are lucky enough to have the source use a vocabulary such as NUCC then you can simple lookup the code to get the concept. But there is really no single vocabulary. Any concept in the domain ‘Provider Specialty’ where the standard_concept = ‘S’ and invalid reason is NULL is a valid to use as a specialty concept id. What kind of values do you have in the source data?

The latest update was 2018-06-09.
Specialties: Christian attached the link above with the structure we’re developing. You can see there that duplicated concepts from NUCC are mapped to corresponding concepts from Specialty/HES Specialty. So, if you have general specialties, I’d suggest using those vocabularies. For more granular ones feel free to use NUCC and ABMS.

Thanks @DTorok and @aostropolets! We actually don’t have specialty data in our source but instead have NPI. Ben was working on mapping NPI to taxonomy codes, which seem to be NUCC codes. But seems like since they’re all standard and not one is preferred over others, we can just stick with NUCC. What do your databases use?

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