OHDSI Home | Forums | Wiki | Github

CARE_SITE and LOCATION in context of providers and visit_details

Implementers
#1

Hi everyone!

I want to create ETL processes, each from a specific medical center, which leads to the OMOP CDM.

Several questions if I may:

CARE_SITE (for providers/visit details in medical centers):

Is it ok to define each care site as a particular medical unit/department in the medical center? E.g. internal medicine A, or internal medicine B or Urology A, etc?

In my case, in each and every single medical center there are multiple care sites. So I think it makes sense to do the above.

Given that I’m doing the above - and every care_site has a unique ID - I need to define, for those care sites’ records, 2 attributes/fields:
location_id and place_of_service (value and concept).

Does it make sense to define, in my case, the location_id as a location of the whole medical center (because then I can link it to the zip code and lat-long coordinates etc.)?

An example (synthetic) of what a record might look like in my CARE_SITE table (displayed as a dictionary}:

{care_site_id: 123, care_site_name: “Urology-A”, place_of_service_concept_id: 45765880, location_id: 1000, care_site_source_value: “D1356”, place_of_service_source_value: 1203}

When 45765880 stands for “Urology clinic” in the SNOMED vocabulary. “D1356” is a string, but that’s my identifier in the source data for that place of service, with the source name: “Urology-A”.

With my above logic, the corresponding LOCATION record may look like this:

{location_id: 1000, address_1: “10 Downing st.”, address_2: “LA Sinai Medical Center”, 
 , location_source_value: “LA Sinai Medical Center, 10 Downing st.”, 
}

My question is: Should the corresponding location describe the exact address of the medical center where the care_site is (as displayed above) or the full exact address of the care_site instead - e.g. {location_id: 123, address_1: “LA Sinai Medical Center”, address_2: “Urology Dpt., floor 3”, 
}.

I love to hear some opinions/suggestions.

Thank you!

1 Like
Mapping Department Specialty to Care_Site
#2

@gil.frenkel:

Yeah, this is a problem we are struggling with. What exactly are Care Sites, and what is the right level you want to set them.

As usual, the use cases will give you the answer: Since this is OHDSI Network research, the exact identity of departments, wards, wings and remote locations of a hospital and their logical relationship to each other (the “Urology Dpt” belongs to the “Surgery Wing” of the “Annex Location” - I am making it up of course) is impenetrable to outsiders. That means, comparing outcomes (e.g. hospital infection rates) in the “Annex Location” to the “Main Location” of the institution with all the departments in each is impossible for folks who have no knowledge of the place. That use case is not addressable in a generic fashion.

The use case that people would like to use Care Sites for are as anonymous entities for things like lines of stratification or propensity model covariates. For example, “How much does the hospital infection rate differ between Care Sites?”, without the precise knowledge which one is your “Urology Dpt”. It is just Care Site #3246. So, pick them with that in mind: What are useful delineations that would be good for stratification and covariates.

The only rule you got is that the granularity in VISIT_OCCURRENCE should be coarser than VISIT_DETAIL, or at least not the other way around. So, “Urology Dpt” would be more likely picked for use in _DETAIL, and “Main Location” in _OCCURRENCE.

Wrt to place_of_service: We are abolishing this for Care Site. Look at the latest CDM V6. It is impossible to assign these Places of Service correctly and unambiguously, and also they really are not a “place” to begin with. Instead, the care setting becomes part of the Visit. The Care Site is only some place you picked to attach a unique ID to according to the above reasoning.

Makes sense? I probably haven’t helped too much.

1 Like
#3

Hi Christian.

I have more information compared to what I had before, so you definitely helped me.

Thanks.

#4

Hello everyone,

Besides using OMOP and Atlas for network studies, as you mentioned here, we also would like to use it for local studies. In that case, it would be useful to be able to create a cohort based on a specific, local care_site.
Right now, it is only possible by creating an SQL script because there is no way to create a cohort based on care_site_source_value using Atlas.

We were thinking a lot about how to solve this issue, and we came up with an unconventional solution: we map our care_site_source value to a vocabulary (non-standard) with a procedure domain → and we put it in the procedure_occurence table.

Our reasoning behind it: because it is not standard, it will bother no one when creating network studies. In this case, a patient might have 21 procedures instead of 20 (the one additional one representing our care site), but the number of procedures is not something to research.

Is there a better solution than this? Does anyone have done this before?

#5

Hello @Agota_Meszaros,

The closest you can get while adhering to the OMOP CDM rules is to use either the concept_id in the Visit Occurrence or Visit Detail tables. But I know both lack the granularity which is sometimes necessary to say “I want all patients who were seen at Clinic XYZ and not any other clinic”.

I have two suggested solutions. One is “perfect”, but a bit more work. However, it would be very well received by our open source community which relies on the generosity of its members to maintain and expand the OMOP CDM and its tools :grinning: The other is adequate for a local solution. But no one else will be able to use it AND Atlas users will need to be continually educated and reminded there is a custom, one-off solution. As my mentor would say, they need to add another sticky note to the laptop to remember the “IF/THEN” scenario. I’m unsure of the tipping point from # of one-off solutions versus build your own solution to incorporate all the one-off solutions. But be cautious in your customizations. I’m speaking from experience!

Best solution: Extend Atlas to include the use of the Care Site table. OHDSI has an Open Source Development WG which will give guidance if you decide to go this route.

Local solution: Instead of using the Procedure table, I would use the Observation table. Being seen at Clinic XYZ is not a Procedure by any definition. It would be considered an Observation, but even that is a stretch. I would use concept_id = 4210125, Attending establishment then put the clinic name in the Observation.value_as_string. Atlas utilizes this field. Skip the concept_id creation. It is not necessary

#6

Hello @MPhilofsky,

Thank you for the detailed answer! We discussed it internally in a meeting, and because right now we are a very small local OMOP team, we do not have the knowledge or capacity to extend Atlas, sadly. So we will go forward with your recommended local solution for now.

I understand your concern about the local solution and forwarded it to my colleagues as well - let’s hope it is only a temporary solution for us.

Cheers,
Agota

#7

I’m interested to know how the solution works out for your team. Please share the results of its implementation you’ve had a chance to use it.

2 Likes
t