Discussion: How to handle GIS data

[marc-outins]

Shawn Dolley brought up a use case of handling GIS data especially in conjunction with wearable devices which could take measurements at any coordinate (not associated with an address). We (Mark, Jen, and Marc) discussed the following options after the meeting:

1. Add lat and longitude as measurement_detail records.
   • The actual measurement (ex. heart rate) would share the same context as the lat and long measurement records
2. Add lat and long columns to contexts table
   • This keeps contexts handling the where and when of a clinical code
   • Potentially make the device a practitioner so we can track that a device made the measurement
     • May need to add practitioner_details table to store other information about the device (manufacture, device id, etc). Would also be useful for regular practitioners to store information about them we currently aren't handling.
3. Add a contexts_locations table that stores location information about a contexts
   • Could move facility_id in here with lat and long so all location information associated with a context is in one table
   • There would never be more than one contexts_location associated with one context so this table wouldn't be necessary other than to group things together

[aguynamedryan]

Option 3 seems like the best proposal so far, but I'd like more detail on what the contexts_locations table stores. The name makes it sound like a join table between contexts and locations, but I don't think that's what you're proposing.

[markdanese]

We could consider a wearable device that measures something to be a "practitioner" as in option 2. But I think this analogy will eventually break down because wearable devices may have ids, operating systems, versions, and other meta-data that isn't like the information a human practitioner record would have.

Perhaps a "device_metadata" table (for lack of a better word) might be a better long-term solution. That way the wearable device can output its data into "measurements" or "drug_exposures" (most obvious use cases). Those values will have a context, and the context can point to the "device_metadata" table that will store the information. That metadata table can point to a devices_locations table, which can store all of the location information.

This may not be the optimal idea, but I think we should think about devices differently from traditional clinical data.