Corrections to location_history
Nobody has claimed this yet.
- Dominant language
- HTML
- Stars
- 1.1k
- Forks
- 508
- Avg merge
- 1h 30m
- Merged PRs (30d)
- 3
Description
Location_history table was proposed and ratified based on this proposal.
https://github.com/OHDSI/CommonDataModel/issues/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, |
| 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.
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Read the proposal in issue 181 and the discussion in issue 220, then compare their decisions with the location_history table requirements here. Resolve the naming, entity-field, relationship-concept, and convention changes, including the need for new concepts; done means the table definition and conventions consistently reflect the agreed model.
Written by the indexing model from the issue text.
Assessment
- Domain
- databases
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100