| OHDSI Home | Forums | Wiki | Github |
Hi all,
can the location information (State concept ID 4161694) be used in Atlas? or is there another way to determine geographical location of the patients?
I checked the ETL for the databases I want to use and it says that the info can be found under the State concept. However, I cannot see any records within this field:
many thanks.
Yes, but not using that concept. and Location concepts are only used in very specific places: either Visit or VisitDetail criteria, using the āPlaceOfServiceLocationā attribute:
Some notes:
this attribute was marked CDM >=6.1 which means it was implemented expecting that there would be a CDM 6.0, but that has been suspended. However, if it was backfilled to CDM 5.4, then it is something that will work on your database. Youād have to check if you have a LOCATION and LOCATION_HISTORY table in your CDM, and if your CARE_SITE table has records that associate a VISIT to CARE_SITE, and then a join between CARE_SITE CS and LOCATION_HISTORY LH where LH.entity_id = CS.care_site_id and LH.domain_id = āCARE_SITEā and the Visit start date falls between the LOCATION_HISTORYās start and end date.
They made Location history pretty complicated, so it might take a little futzing to know if you know if your data is set up to use locations, but, if it is, then you can look for PlaceOfServiceLocation of Visit/VisitDetail using those location concepts. Locaton concepts in vocabulary are hierarchal, so you can go to something like Country->state->county using concept set expressions.
Btw: from your screenshot, I donāt think that concept is exactly a location region, but rather a concept that represents a āstateā. You donāt need that concept but rather the concepts that represent location concepts in the vocabulary.
@clairblacketer , please confirm if LOCATION and LOCATION_HISTORY is actually part of CDM 5.4. If not, then the answer to the above is āno, you canāt use location concepts in atlasā.
Excellent question! Our researchers ask about specific locations for trial recruitment, so I took a look in Atlas.
The geographical location of a patient is found in the Person table using the location_id to link to the Location table.
In Atlas, you canāt use a Personās attributes as the Cohort Entry Event. But you can use Location as Inclusion Criteria by clicking on the āLocation Regionā drop down:
*Note: this is a Personās current location. Historical location is in the Location History table.
When you want to create a concept set for a specific location, you need to search on domain_id = āGeographyā and standard_concept = Standard. You will also want to include all the children concepts because I have seen rows of source data which lack a state information, but does have the city present.
The Location History table is not available for query in Atlas. So, past locations for a Person or Care Site would have to be queried against the database.
@Chris_Knoll @MPhilofsky Thank you both for the detailed answers!
Current location would suffice for me, I donĀ“t need historical location.I checked the standard concepts within the domain Geography in Athena and I did a search based on these within Atlas (as suggested by MPhilofsky), but still there was 0 resultā¦any idea why?
It would be great if the solution suggested by Chris Knoll could be confirmed by @clairblacketer, whether these tables are available in CDM 5.4.
Everything in the CDM is āhistoricalāā¦thatās part of the confusion with how locations work in the CDM, but there is a reason for this: Locations are things that could be re-used between time intervals (the actual historical location), so you could think of Locations as a āconcept table for locationsā and the āLocation Historyā as the observations of location during a period of timeā¦like a care site can move locations over time, so one care site can have multiple locationsā¦maybe this was done for ambulatory purposes? Not sure, but someone may have the reasons.
If it was to be done again, maybe just taging visits a new column ālocation_concept_idā so that you could simply find visits based on a hiearchy of regionsā¦but I think locations were meant to store physical addresses of things in your data, so you canāt encapsulate all that information in a conceptā¦hence the need for a ālocationā tableā¦but Iām still confused about having a history table to represent a time window for a particular locationā¦as if a building could get up and move.,
But now that I put it that way, now I think the location is associated to a person, not a physical address, so that would explain/justify the location_history table: location is the where, location_history is the when patient lived at the particular location.
Looping back to the statement you made that I quoted: there is no ācurrent locationā information in the CDM, just like there is no ācurrent health statusā in the CDMā¦everything in the patient record is time-indexed, and Location was no exception.
