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 Provider Specialities #43

Closed
clairblacketer opened this issue Oct 30, 2018 · 8 comments
Closed

Multiple Provider Specialities #43

clairblacketer opened this issue Oct 30, 2018 · 8 comments

Comments

@clairblacketer
Copy link
Collaborator

clairblacketer commented Oct 30, 2018

TYPE NOTES
ITEM How do we handle providers with multiple specialties?
FORUM POST http://forums.ohdsi.org/t/new-comprehensive-hierarchy-for-providers-visits-and-place-of-service-specialty-care-site/5633
SOLUTION Currently there is a convention:
A single Provider cannot be listed twice (be duplicated) in the table. If a Provider has more than one Specialty, the main or most often exerted specialty should be recorded.
NEXT STEPS Understand from @cgreich how this should be working given what is now in the Vocabulary. Supposedly there is a hierarchy now.
@ericaVoss ericaVoss added this to the Release V2.0.0 milestone Oct 30, 2018
@cgreich
Copy link
Contributor

cgreich commented Oct 30, 2018

And how do we know if two records are the same guy?

@clairblacketer
Copy link
Collaborator Author

Same NPI or SOURCE_PROVIDER_ID?

@cgreich
Copy link
Contributor

cgreich commented Oct 31, 2018

Ugly. We have the same NPI, but a different provider_id? Half of the folks will get confused.

@don-torok
Copy link

It would be nice to see an example. How is the provider defined in the medical encounters? Do you have both provider id and specialty or just a provider id? If the latter, then ETL will again have the problem of having to choose one or the other provider.
If it is necessary to maintain multiple provider specialties add a table provider_specialty (provider_id, specialty_concept_id, rank). You will still have the problem of choosing the primary specialty (which should also go into the provider table) but will as least be able to maintain the source information that provider has more that one specialty.

@cgreich
Copy link
Contributor

cgreich commented Nov 1, 2018

Friends:

Here is what I will do. I will pull the list of these multiple-specialty docs and check it against the specialty hierarchy we are building. Because in the real world there are almost no true double-specialty docs. Trust me. It takes a lot of time, and a lot of training, and a lot of examinations, a lot of lost income to get there. What's happening a lot is like a "cardiologist" will also call himself "internist" in another circumstance. But of course cardiology is a subspecialty of internal medicine.

I will report back how bad the situation really is.

@stephanieshong
Copy link

stephanieshong commented Feb 1, 2023

a provider with a NPI number can be a care_site, a hospital, with multiple specialty associated with it. (i.e. outpatient specialty clinic, hospital and a hospice.)
a provider as a physician who took care of a patient can be medpeds in US, who is both internal medicine and pediatric specialty doctor.
Not being able to add specialty value associated with the same NPI is causing a problem both in provider and the care_site table.

@cgreich
Copy link
Contributor

cgreich commented Feb 1, 2023

@stephanieshong:

  • NPI: That is correct. In the CDM, we only collect Entity Type 1 providers: Individuals, including sole proprietors. And, to be honest, I think even that is TMI.
  • Specialty of organizations: We do not model those. We had debates about that. It wouldn't work.
  • Medical pediatrics: No problem adding that as a concept, as descendant of both Pediatric Medicine and Internal Medicine. Strangely, there is no such thing, even though we have tons of mixed pediatric specialties (look under "Subsumes").

@MelaniePhilofsky
Copy link
Collaborator

Closing this issue. Vocabulary and CDM conventions were updated.

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

No branches or pull requests

6 participants