Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Multiple Specialties per Provider #183

Open
AgnesWW opened this issue Apr 29, 2024 · 1 comment
Open

Multiple Specialties per Provider #183

AgnesWW opened this issue Apr 29, 2024 · 1 comment

Comments

@AgnesWW
Copy link
Collaborator

AgnesWW commented Apr 29, 2024

What to do when we have more than one specialty per provider

CDM or THEMIS convention?

THEMIS

Table or Field level?

field in PROVIDER table: specialty_source_value

Is this a general convention?

Not a general convention, however sometimes the same strategy may be devised for the other fields - for example most frequent value for race was utilized in some implementations in the past.

Summary of issues

Established convention: If the provider has more than one specialty ETL needs to assign only one in the field specialty_source_value on the PROVIDER record.

Summary of answer

We are selecting the most frequent specialty per provider

*An alternative new method is under the discussion/development: using the assigment based on the specialty hierarchy.

Related links

#43

There was work done on provider specialties hierarchies:
https://forums.ohdsi.org/t/new-comprehensive-hierarchy-for-providers-visits-and-place-of-service-specialty-care-site/5633
https://docs.google.com/spreadsheets/d/1A4OFGoJtRCz-G5qju-TrR5UDFX7coXwuRo7Yw5KSslo/edit#gid=0&fvid=66134107

Under this link we read "Specialty is a degree or qualification of a provider (a flesh and blood provider), and the Domain is Provider."

Other comments/notes

Also there was a meeting on January 21, 2022 focusing on modifications to the convention of mapping the specialties
https://forums.ohdsi.org/t/cdm-themis-workgroup-meeting-21jan2020/9285/2

There are some notes about mappings

If a Provider has more than one Specialty, there are two options:

  1. Choose a concept_id with an “Is a” relationship 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. If a provider’s specialty is not represented either as a singular concept or a concept with an “Is a” relationship to the multiple specialties, put a zero in this field and record the specialty in the specialty_source_value.
    Abover are not published yet on CDM v5.4
  • Please use this section to add any other relevant notes or comments. (i.e. if links are not working, something is out of date or deprecated)

Older links quote the convention #3 under provider See Erica's

But was commented in the light of work on hierarchies (Gowtham_Rao):
"This probably needs to be updated with more specifics - considering the updates to specialty that [@Christian_Reich] is introducing - along with hierarchy."

The provider mappings may have some discrepancies or sometimes need some extra work on the vocabulary side: https://forums.ohdsi.org/t/provider-mappings/13652 The vocab team recommendation for the future was in cases of inambiguity to use the order of vocabularies: Medicare - ABMS - NUCC - HES for mapping of specialties

@MelaniePhilofsky
Copy link
Collaborator

MelaniePhilofsky commented Jul 18, 2024

Ideas generated on July 18, 2024 call:

  1. NPI can be linked to the National Plan & Provider Enumeration System (NPPES) to identify a Provider's specialty. This sometimes contains a Provider's primary specialty. US centric solution, assumes you have a Provider's NPI.
  2. Utilize the Provider's primary care site to identify a specialty based on the specialty of the care site. Assumes you have care site information for a Provider and the care site has a specialty associated with it.

We need input on OHDSI/network study use cases which utilize a Provider's specialty. Please comment below with the use cases.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants