OHDSI Home | Forums | Wiki | Github

Location change

CDM Builders
#1

@SCYou and I have been linking location and GADM database to study air-pollution using GIS.

The location information of patients are contained in the person table. However, the change of the location information can not be updated because of the structure of the table.

I wonder if the THEMIS-Focus Group 4 and the GIS Working Group are also aware of this concern and are going to continue working on to fix it.

I think inputting the location information in the observation table would be an alternative

example (arbitrary value) :

image.png754×178 37.5 KB

observation_concept_id = 4077707(Location)

2 Likes
#2

@rtmill
This seems to be a good approach, instead of location_history ? Use observation_start_date and observation_end_date for date ranges the person was in the location. Use value_as_number for the location_id.

@SCYou @Jaehyeong_Cho what concept_id are using for observation_concept_id and observation_source_concept_id ?

#3

Friends:

Can you add this to the official proposal? And wake up @Ajit_Londhe, @Gowtham_Rao and @rtmill to move this thing forward?

1 Like
#4

i like this proposal to capture location history in the observation table.
we could consider using the existing standard concept ‘patient address’ (
http://athena.ohdsi.org/search-terms/terms/4083586) and then include the
locationid as you have suggested. i think the locationid in person table
still makes sense to reflect the person’s current/last known location,
which is often the only information a database contains. but adding a
convention to capture location history in observation for circumstances
where that exists could be helpful.

1 Like
#5

@Christian_Reich , @rtmill and I talked yesterday urging to move this forward. At the minimum we can move forward with adding latitude and longitude to location table as proposed here https://github.com/OHDSI/CommonDataModel/issues/91
We agreed that we can bring these up for discussion with little cleanup (eg what is a region?). We will work on they prior to next cmd wg meeting.

The dilemma that was holding the GIS group back was how to represent geographic unit level information in a person level data model. Most publicly available datasets have attributes at geographic unit level e.g. income and census. if you have the average income information about persons living in a zip code, how do we use that in person level Omop cdm. Should it be extrapolated to person level, or should we define every possible geographic unit as standardized vocabulary with hierarchy, and link persons to the geographic unit. Extrapolation to person level is easier.

Next dilemma is, what vocabulary and concepts do we use if we want to capture income, education, employment etc.

But the two dilemmas should not hold back adding lat and long, or using observation table for location history IMO

#6

This standard concept_id makes sense. It already belongs to the domain of Observation. Thank you

#7

@Christian_Reich I’m awake!

This is good timing as we just put something together. I would very much like to avoid putting the location history into the observation table. The GIS functionality we are working towards will be reliant on querying this data often.

Here’s how the GIS WG has been planning to handle location history:

image.png650×706 31.2 KB

#8

Maybe it’s a revision for the location table, so instead of a geometrical point it can denote an area?

Good morning! :smile:

@clairblacketer: Want to joint it with our CDM isues and bring these people on in one of the next sessions?

#9

@Christian_Reich that’s a great idea! I’ll look at the upcoming agendas and figure out where we have some room.

#10

Changing the representation of location from place to region would not be helpful for us. That said, there is another discussion about reworking the location table for other purposes here.

The issue isn’t ‘how can we relate a region to a person’ (person<->location history<->location<->coordinate<->region). The issue is ‘how can we represent these spatial concepts in a proper and consistent way in the CDM’. We’ve been struggling to find any existing person-level vocabularies that could be leveraged, which also has a relevant post here.

In other words, the coding exists (census, EPA, etc) but it represents the concepts at a region level which isn’t directly translatable to the person level (e.g. poverty rate for census block != person lived in area with poverty rate) . However, for the most part, the data be adequately represented by a combination of concepts from existing vocabularies, though it is unclear if and how this should be done. (Discussed in this post and, according to the issue list, it looks like THEMIS group 1 plans to discuss it)

There’s a lot of relevant posts at the moment

#11

@rtmill, ‘Location_history’ table is just what we’ve wanted!
But, if we can store location history in observation table, then we don’t need another table).
As the version of OMOP-CDM has been upgraded, the table and columns has been increased, too. I’m concerned about this.
My claim database has location history. But EHR data doesn’t have location history (it only has ‘current location’). So for EHR data, we don’t need location_history table.
Although I really wanted ‘location_history’ table, but I think we can store the exact same information in observation table. And this doesn’t spoil any principles of OMOP-CDM!

@Christian_Reich Of course, we will add this to the official proposal!

#12

@SCYou It sounds like this is a viable solution for your needs. That said, we’d like to establish a long term strategy. There are quite a few interested parties that have location history from EHR data.

If that’s the logic we’re using then why have a measurement table? I’m sure we could squeeze death records into observation as well.

Efficiency concerns aside, I don’t think we can. The observation table stores ‘clinical facts about a person’, and is person-centric. A history of location relationships is location-centric, capturing relationships between location and any other applicable domain, not always person. For instance, say you want to do distance to care calculations and ‘ABC Family Medicine’ moved locations in 2013…

I mean to say I think we could use the observation table, but should we?

1 Like
#13

I agree with Robert’s perspective: the purpose of observation is to record patient level phenomena about something that’s occurred to them. And the observation table doesn’t have an end date, but a history table would presumably have a start-end period.
.

#14

I agree. We need location history for persons and care sites. And care site locations shouldn’t go into the observation table for the reasons @rtmill stated.

+1 We are ready to use the proposed latitude & longitude fields.

#15

Seems it looked like a good idea to use the OBSERVATION table, but I agree, it wasn’t.

#16

@Christian_Reich @MPhilofsky @rtmill
Recently, I and @Jaehyeong_Cho are working on phenome-wide association study analyzing relationship between air pollution and the diseases. We’ve already converted whole Korean air pollution data to fit in location table of OMOP-CDM based on GADM.
One of the biggest problem for us is that current OMOP-CDM doesn’t represent the location of person at the specific moment.
That’s why we need a strategy for storing location history (whether adding new table or using existed table). As I said, the location history table is just what I’ve wanted. It would be much easier to make a tool if we have independent table for location history.

I hope this could be updated soon!

2 Likes
#17

@SCYou @Jaehyeong_Cho Can we invite you to have a discussion about this in the THEMIS Group 4 bi-weekly meeitngs? The meeting is a bit late for you so we can schedule a separate time that will work for you gentlemen. This way, we can talk through it and see how we want to propose any changes to the CDM working group.

#18

As @Christian_Reich stressed, use-case is very important. @SCYou seems have his use-case. If location table can be added to OMOP-CDM soon, it will be great. If not, he may need any of tentative but quick solution.

#19

@mvanzandt Sure, why not? but 2 PM EST seems a little tough. (It is 4 am in Korea time.)

May I have a meeting at another time?

#20

Guys, could we please bring to the cdm wg change that allows us to incorporate latitude and longitude? That change should be a consensus.

https://github.com/OHDSI/CommonDataModel/issues/91#

1 Like
t