Location History Table

[clairblacketer]

This is a link to the location history table proposal on the GIS githhub page. This proposal was accepted on 5/10/2018 and will be added to an upcoming version of the cdm.

[gowthamrao]

Instead of entity_id can we call it entity_concept_id

[clairblacketer]

@gowthamrao I don't know that entity_concept_id would fit, the idea is that the field would house something like a person_id or a care_site_id

[gowthamrao]

Thank you for the clarification.

[clairblacketer]

reopening this since it has not yet been added to the cdm

[gowthamrao]

Initially posted here 5d26033

@clairblacketer @cgreich @pbr6cornell

The location_history table is going to be an extremely large (EAV) like table. Currently we have two varchar(30) columns

• relationship_type with values 'residence', 'work', 'school' etc
• domain_id with values 'PERSON', 'PROVIDER', 'CARE_SITE' etc

Can we convert these to integers - using concept_id

i.e. instead of relationship_type, change to relationship_type_concept_id
domain_id to domain_concept_id or table_concept_id (to differentiate between tables belonging to same domain_id like visit_occurrence and visit_detail)

Integers would be expected to lead to better performance, I think. Plus, it would achieve the same end-goal that the CDM WG wants to represents in this table.

[clairblacketer]

@gowthamrao we are going to discuss changing all domain_id references to table_concept_id at the September CDM meeting. I agree it would help cut down on confusion where two tables have the same domain.

[clairblacketer]

@rtmill how do you feel about the relationship_type_concept_id field?

[cgreich]

I agree with both.

[rtmill]

@clairblacketer @gowthamrao @cgreich That was the plan for relationship_type (create a small vocabulary) and I agree it also makes sense for domain_id. This seems similar to the way domains are represented in the FACT_RELATIONSHIP table?

then it would be:
relationship_type -> relationship_type_concept_id
domain_id -> domain_concept_id
?

The question I remember during the proposal was whether or not we should include relationship_type_source_value.

[clairblacketer]

@rtmill from the proposal it looks like there will only be four options for relationship_type_concept_id ('residence', 'work site', 'school', NULL) so I don't see the need for a *source_value field. We can always add it later if the use case comes up.

In terms of domain_concept_id, we will most likely be moving to table_concept_id instead as there are multiple tables with the same domain (visit_occurrence, visit_detail) which makes it tricky for other tables that reference domain, like COST. For now we will keep it as domain_id until a decision is made on 9/4.

[clairblacketer]

added in v6.0