Care sites and specialty, specialty code clean-up

[Gowtham_Rao]

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.

THEMIS - Focus Group 4 - Decisions/Updates

I wanted to provide an update regarding the care site specialty that we were discussing on Thursday. I can share with you what we do -

At PEDSnet, we have a specialty_concept_id for our care_site table. This value set is the same value set as the value set for provider.specialty_concept_id (concepts where domain_id=‘Provider Specialty’ and vocabulary_id in (‘Specialty’, ‘ABMS’,‘NUCC’)). The ABMS mappings are the preferred mappings and contributing sites can provide NUCC codes if there is not an adequate ABMS mapping.

We ask that if care site specialty information is unavailable, it just gets mapped to one of our flavors of null. If a care site has multiple specialties, we ask that sites extract the most general specialty that encompasses the multiple specialties available within that care site. If multiple specialties are contained within a particular care site and there is not a way to assign a general specialty, then it gets mapped to a the non-specific concept ‘Pediatric Medicine’ (38004477).

We decided to include care site specialty because it provides information about the specialty practices a patient requires. Additionally, if a patient is seen by a provider that has multiple specialties, care site specialty can provide more accurate information about the purpose of a particular visit. Also, care site specialty information can be useful for sites that have poor provider specialty mappings or do not assign specialties well. I can speak from experience in using the database that having a specialty_concept_id contains very useful information about services rendered and is informative for phenotyping patients. It is often the case that a provider specialty can not be assigned to a particular visit (e.g., if a patient was seen by multiple providers or if provider specialty is unavailable), so having the care site specialty is informative. It also provides useful metadata about the setting in which a patient was seen that is not readily available elsewhere.

Provider Specialty code set clean up

Specialties may apply to care-sites. E.g. ‘Short Term Acute Care Hospital’, ‘Long Term Acute Care Hospital’, ‘Urgent Care’ - so we need to ensure that is covered when we update vocabularies. @Tom_Galia @bailey do we need to add ‘Specialty’ to care_site table?

Potential for non-individuals in the provider table

The source data for one of OUR OMOP conversions at IQVIA has a significant percentage of type 2 (non-individual) providers in their provider table. Type 2 providers are typically locations.

Potential for non-individuals in the provider table

we have non-individual providers retained in our data when they’re administrative constructs that provide useful information (e.g. specialty) that’s different from location. So while I might not argue for retaining a “provider” of “Orthopaedics Clinic North”, I might for “Orthopaedics Physical Therapy Provider” as a meaningful local generic.

Potential for non-individuals in the provider table

It is a common practice to have specialty codes referring to care sites. @bailey I think it is an important information to bring up.

[Christian_Reich]

Friends:

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?

[Christian_Reich]

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.

[MPhilofsky (Melanie Philofsky)]

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?

Specialty: These are medical specialties. The kind of thing you can specialize as a physician, or that institutions (wards, department) organize their work around

Are Acupuncture offices and Physical Therapy clinics not institutions?

Therapists and all sorts of other personnel that charges the CMS for services are NOT providers according to this logic.

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

rename the place_of_service_concept_id to care_site_id

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?

[Christian_Reich]

@MPhilofsky:

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.

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

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.

[Gowtham_Rao]

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?

[Christian_Reich]

@Gowtham_Rao:

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?

[Gowtham_Rao]

@Christian_Reich

the new Place of Service is now something that characterizes the organization depicted in СARE_SITE

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.

@Christian_Reich

And leave the VISIT with the 5 big ones?

No

[Gowtham_Rao]

Referencing prior discussions on this topic

Visit vs place of service

Vocabulary Place of Service belongs to the domain Place of Service and is used to populate place_of_service_concept_id in the care_site table.
Vocabulary Visit belongs to the domain Visit and is used to populate Visit_concept_id.
Vocabulary Place of Service is mapped to Visit in both concept_relationship and concept_ancestor table (I dont know how complete this is @Dymshyts ?) Place of Service is a child of Visit

There is a n:1 relationship between visit_occurrence table and care_site table - so there may not be more than one care_site_id per visit_occurrence_id record. As an extension, there may not be more than one place_of_service_concept_id per visit_occurrence_id.

Would it then be reasonable to add all the concept’s in Place of Service vocabulary from Place of Service domain into Visit domain, as a standard_concept and maintain hierarchical relationship?

I wanted to ask - of the 59 standard and about 487 total concept’s in the Place of Service domain, can we change their domain to visit - so that they may be used in the visit_occurrence table as either visit_concept_id and visit_source_concept_id?

The classification of visit’s into inpatient and outpatient is then natural using the concept ancestor table

Visit vs place of service

I think we need to answer the question: why do we need the domain_id “Place of Service”. Why can’t it be “Visit”.

I don’t think we need “Place of Service” domain_id, because we are mapping the standard Concept’s in that domain to standard concepts in “Visit” domain.

Visit vs place of service

@Gowtham_Rao:

Because Place of Service doesn’t denote something that further qualifies a Visit, but a Care Site where the visit happened. And for that we have the table CARE_SITE.

Visit vs place of service

Yes, if we change the field name from place_of_service_concept_id to caresite_source_concept_id and caresite_concept_id. This is obviously not backwards compatible, but will be consistent with Omop CDM conventions. Maybe done for CDM 6.x

Visit vs place of service

In US health care, care-site is not a ‘credentialing’ information, but a ‘claim’. e.g. place of service information comes in every claim on CMS 1500 form.

Visit vs place of service

We (@Christian_Reich @Dymshyts @Dave_Kern @Gowtham_Rao) worked on cleaning up these concepts, and would like the communities input. See document. We propose to change the domain for the vocabulary ‘Place of Service’ (standard concept) to ‘Visit’, because we found that ‘Place of Service’ is an attribute of the Visit and not attribute of ‘Care Site’ as discussed here.

Visit vs place of service

In the US health Care claims system, HIPAA place of service is an attribute of the visit and not caresite. Why - because it is information that is provided at the claim level.

https://www.cms.gov/Medicare/Coding/place-of-service-codes/Place_of_Service_Code_Set.html

Mapping that into higher order visits are done using omop generated vocabulary. That mapping was done by the OHDSI community in past one month and information was shared on this forum. Active roles were played by

[cukarthik (Karthik)]

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

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?

[Gowtham_Rao]

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

@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

but I guess you are suggesting an additional field to the visit table?

No changes to visit table being proposed.

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…

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.

[aostropolets (Anna Ostropolets)]

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.

[BWebb (Ben Webb)]

@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)

[DTorok (Don Torok)]

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?

[aostropolets (Anna Ostropolets)]

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.

[rchen (Ray Chen)]

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?

[Christian_Reich]

Specialties: Christian attached the link above with the structure we’re developing.

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