How to best represent regions was a hotly debated topic in the GIS WG that was set aside while we work on schema and vocabulary decisions. Due to the current focus on location data from THEMIS, we'll plan to revisit this conversation in our next meeting and relay the results back to the forums.That said...
I believe there should be a strong distinction between location and region. A location is a place, represented by a point, where a region is an area, represented by a polygon. Trying to store and reference the two as equivalent unnecessarily creates issues, such as...
If the location table solely contains locations, or points, this is not an issue.
The plan is to submit a detailed proposal once we nail things down but in the meantime, here's a snippet from an old schema draft:
First, the biggest obstacle in designing this was that (I believe) a majority of the OHDSI community uses the location table to refer to regions. In other words, their source data does not contain street level address data. I have encountered ETLs where the location table only stores unique zip codes and maps thousands of individuals to the same 'location'. Initially I attempted to reconcile this by including a 'location_type' field in the location table which designated the location as either a place or a region. Building off of this, queries and attribute assignment gets messy and inefficient.
I'm proposing a different model in that any record in the location table refers to a specific location, never a region. If the source data only contains zip codes, then a record in the location table should not refer to the region itself but to 'a location somewhere within the region'. It's seems like a trivial distinction but the effects echo throughout the rest of the design.
If you have a location table that contains only locations, a region table that contains only regions and a mapping table to go between the two, it significantly simplifies things (we then don't have to check the location table for regions, store varying data types, reference polygons vs. coordinates, etc).