Corrections to location_history

[gowthamrao]

Location_history table was proposed and ratified based on this proposal.
#181

Based on the conversations here - we would like to request the following corrections to location_history table.

The LOCATION HISTORY table stores relationships between Persons or Care Sites and geographic locations over time.

Field	Required	Type	Description
location_history_id (new)	Yes	integer	A unique identifier for each location history record (PK).
entity_id	Yes	integer	The unique identifier for the entity. References either person_id, provider_id, or care_site_id, depending on entity_field_concept_id.
location_entity_field_concept_id (new)	Yes	integer	A foreign key to the field of CDM table that is to be joined to the entity_id.
location_id	Yes	integer	A foreign key to the location table.
location_relationship_concept_id (renamed)	No	integer	A foreign key that refers to a Concept identifier in the Standardized Vocabularies belonging to the 'Location Relationship' Vocabulary to represent the relationship between location_id and person_id/care_site_id.
location_history_start_date (renamed)	Yes	date	The date the relationship started.
location_history_end_date (renamed)	No	date	The date the relationship ended.

Changes:

• renamed relationship_type_concept_id as relationship_concept_id - to avoid confusion. Type concepts have specific meaning in OMOP CDM related to provenance of the data.
• converted relationship_type_concept_id from varchar to integer, and changed its description to be consistent with OMOP convention.
• replaced domain_id and entity_id with explicit person_id and care_site_id. After much discussion, we all agreed that only two types of entity's would have location: they are the person_id and care_site_id. Provider_id would not directly have location_id because provider_id's are nested withing care_site_id's, and care_site_id's have location_id.
• added entity_field_concept_id as the concept_id of the field of the table the entity_id maybe joined with.
• just using 'start_date' and 'end_date' maybe ambiguous. In OMOP we use visit_start_date, condition_start_date etc. Using the same type, location_start_date and location_end_date is proposed instead of just start_date and end_date

Changes to conventions statements below

Conventions

No.	Convention Description
1	The permissible values of relationship_concept_id are: 'home location' , 'vacation home location', 'physical location'. For care_site_id (event_id) the relationship_concept_id will always be physical. For persons the relationship_concept_id may be 'home', 'vacation home'.

Need new concept's to be assigned.

[clairblacketer]

@rtmill @AEW0330 Can the GIS group take a look at this proposal and let us know if the CDM WG should keep it on the table for discussion or drop it?

[AEW0330]

Thanks for the prompt Clair. Please keep it on the table or at least let's hand it off to the Vocabulary WG if that's where it belongs. Either way it's still alive and, in my opinion, should be expanded to include relationships for where people work and go to school as Robert and I originally proposed.

We'll put this on an upcoming GIS WG agenda. More pertinent the CDM schema, we will add add a "revive Location_History" project and a corresponding issue for it to our GitHub repo and link it to an issue here in the CDM repo. Atting Marty, Kyle and Polina here also to make sure we get to all that.

[clairblacketer]

Thank you @AEW0330! I moved this to the On Hold: Future Version bucket for now since LOCATION_HISTORY is a v6 artifact. If you all have an argument for including this in our 2026 v5.x version instead of a future major version, we can make some time on an upcoming CDM call to discuss.