OHDSI Home | Forums | Wiki | Github

CARE_SITE and LOCATION in context of providers and visit_details


(Gil Frenkel) #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!


(Christian Reich) #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.


(Gil Frenkel) #3

Hi Christian.

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

Thanks.


t