Open marc-outins opened 6 years ago
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.
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.
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: