QI_omop
April 19, 2019, 3:39pm
3
@Christian_Reich
Regarding hospital attribute use case, I will ask client’s permission to post it. As for other attributes, we can discuss in detail what their definitions are and how they have bee used in clinical research.
But the main point I want to bring up is that by adding this table (Dimension_Attribute) to the CDM, we have a holistic approach to all the dimension attribute issues listed out there, such as the ones below:
Region_concecpt_id - hotly debated right now.
I’ve been heavily lurking on this chain with great intrigue. I feel a bit like the Mueller report. No real conclusion and yet the dialogue is telling. @rjking – maybe this is where you could help
opened 06:28PM - 13 Mar 19 UTC
closed 04:32PM - 01 May 23 UTC
Accepted
## Location table changes (add region_concept_id)
**Proposal Owner:** Pavel G… rafkin, Gowtham Rao
**Discussion:** https://github.com/OHDSI/CommonDataModel/issues/220, https://github.com/OHDSI/WebAPI/issues/649
**Proposal overview:**
- Add `region_concept_id` column to `location` table
**Description**
We would like to use administrative areas as part of cohort entry event, cohort inclusion criteria, enhance cohort characterization using the areas, create heatmaps and do clustering based on the areas.
To achieve this, as a first step, Geo Vocabularies were proposed (https://github.com/OHDSI/WebAPI/issues/649#issuecomment-440757591) and implemented (https://github.com/OHDSI/Vocabulary-v5.0/pull/207). The geo vocabularies represent ontologies of administrative areas (e.g. Country -> State -> County -> Township).
The second necessary step is linkage of records in `location` table to the administrative areas. Even though the relations of geo concepts and locations represent derived information, not all of OHDSI supported DBs have geo capabilities (and therefore we cannot compute the relations between a location and geo concepts inside DB - https://github.com/OHDSI/WebAPI/issues/649#issuecomment-440757591) plus the computation of the relations is pretty compute intensive to do it on-demand, therefore there is a need of pre-calculation and physical reference storage. We need to store only a link from a location to its lower-level administrative area (concept_id). Other, higher level administrative areas, can be retrieved via `concept_ancestor`.
**Location to administrative area pre-calculation**
*(using Postgres)*
1. Load a CSV with concept_id to polygon relations (https://github.com/OHDSI/Vocabulary-v5.0/pull/207#issuecomment-469859598) into the table:
```
CREATE TABLE area_polygon (
concept_id INTEGER,
polygon VARCHAR
);
```
(where `polygon` stores GeoJSON)
2. Precalculate relations between LOCATION and lowest level areas:
```
CREATE INDEX area_polygon_geom ON area_polygon USING GIST (ST_SetSrid(ST_GeomFromGeoJSON(area_polygon.polygon), 4326));
CREATE INDEX location_point ON location USING GIST (ST_SetSrid(ST_MakePoint(longitude, latitude), 4326));
WITH lowest_level_areas AS (
SELECT area.*
FROM area_polygon area
WHERE NOT EXISTS (SELECT * FROM concept_ancestor WHERE ancestor_concept_id = area.concept_id AND min_levels_of_separation > 0)
),
loc_area AS (
SELECT l.location_id, area.concept_id
FROM location l
JOIN lowest_level_areas area ON ST_CONTAINS(ST_SetSrid(ST_GeomFromGeoJSON(area.polygon), 4326), ST_SetSrid(ST_MakePoint(l.longitude, l.latitude), 4326))
)
UPDATE location
SET region_concept_id = la.concept_id
FROM loc_area la
WHERE location.location_id = la.location_id;
```
**Proposed implementation**
https://github.com/OHDSI/CommonDataModel/pull/251
Specialty & Add Clinical Title #49
opened 03:44PM - 27 Nov 18 UTC
closed 04:50PM - 05 Jul 23 UTC
TYPE | NOTES
-- | --
ITEM | Provider specialty not well captured in the Vocabu… lary.
FORUM POST | http://forums.ohdsi.org/t/provider-specialty-code-set-clean-up/3888 <br> <br> http://forums.ohdsi.org/t/care-sites-and-specialty-specialty-code-clean-up/4538/4<br> <br> http://forums.ohdsi.org/t/new-comprehensive-hierarchy-for-providers-visits-and-place-of-service-specialty-care-site/5633
SOLUTION | Incorporate NUCC, ABMS, HES Specialty, and Specialty-CMS. The order of preference should be OMOP->Specialty->Place of Service->NUCC->ABMS->HES Specialty->UB04
NEXT STEPS | Ultimately the Vocabulary team will work on. Double check this has been implemented in the Vocabulary. Maybe we need to remove duplicates.
Multiple Addresses per Provider #48 https://github.com/OHDSI/Themis/issues/48
These are just a few examples. I am sure in the future people will want to add more dimension attributes to the existing dimension tables. By adding this new table, we provide a solution to all.