Closed pavgra closed 1 year ago
What kind of unit_concept_id is 2110000000?
This should be a unit of distance, e.g. miles (so something similar to http://athena.ohdsi.org/search-terms/terms/4121361). And I believe Geo Vocabs should introduce such concepts
Units are in domain "Unit" and vocabulary "UCUM". And the question is if we want to standardize to km and get rid of the field altogether. Otherwise it is concept_id={9536, 9546, 9363}
Otherwise it is concept_id={9536, 9546, 9363}
Nice to know, thanks
And the question is if we want to standardize to km and get rid of the field altogether
Since it simplifies things, sounds good for me. Anyway, Atlas / other tools will be able to convert units and therefore still allow end-user to work with any unit types
So nearest LabCorp may be 5 miles and nearest dialysis facility may be 15 miles. To calculate distance, (and assuming patient home is point A) - what are the specs for point B ?
This is going to be discussed at the 4/9/2019 CDM meeting
Here is the link to the vote for this proposal. If it passes it will go to the dev branch first and then a later discussion an vote will be held to put it in production.
What is disadvantage of adding longitude and latitude as attributes of location table, other than they will be NULL for the vast majority of CDMs. Then location can be determine via your query.
Closing as latitude and longitude were added to the location table.
New derived table: location_distance
Proposal Owner: Pavel Grafkin, Gowtham Rao
Discussion: https://github.com/OHDSI/CommonDataModel/issues/220, https://github.com/OHDSI/WebAPI/issues/649
Proposal overview:
location_distance
- to store distances between patients and care sitesDescription We would like to introduce:
So, we need to know the distances between people and care sites. Even though the distance between a person and a care site represents derived information, not all of OHDSI supported DBs have geo capabilities (and therefore we cannot compute the distances inside DB) plus the computation of the distances is pretty computationally intensive to do it on-demand, therefore there is a need for pre-calculation and physical data storage.
Performance considerations
Some of the questions raised during the discussions are related to volumes of the data and performance of queries.
Amount of relations can be described by
number of Person * average number of Locations per person * average number of Care Sites a person visits during life in a Location
and hardly will raise up to the sizes of the main domain tables (e.g. drug exposure, condition occurrence and so on). E.g. the median number of drug exposures per person in Optum is 44, the average is 61. I doubt that each person in DB will change 10 houses while visiting 4-6 care sites with different locations during life in each of houses.Therefore, I would assume that the table might grow to the sizes of one of the main domains tables and so the quering performance will be equal. I cannot provide actual numbers since don't have access to any CDM v6 database which would hold location_history data. Maybe @gowthamrao can share some numbers (and I will try to get numbers w/o location history from some typical datasets)
Table format
location_distance
Distance pre-calculation