Hi, we are working on a digital health project containing some IoT data like air quality of the room the person staying in. What is the appropriate way to handle this kind of environment data? Many thanks!
There is no appropriate way to handle data like air quality of the room the person staying in because the CDM was not built to hold such information. That being said, along with the standard question of “do you have a use case for keeping this information?”, you can either try to fit the data into the Observation table, or better yet create your own table that you can link to using patient_id and visit occurrence or visit detail id. Your own table will be a better solution because you can tailor the column names and data type to suit the information that you plan to keep.
You may want to join GIS Work Group meeting. There might be discussion on the subject.
GIS-Geographic Information System WG GENERAL Meeting: Wednesday, April 6 at 11am ET (Meeting Link)
Meetings are traditionally scheduled for every other Wednesday at 11am ET.
Thank you Qi! I just saw this and missed this week’s meeting. Will try to join next Wednesday.
Thank you Don for the suggestion. I try to read TheBookOfOhdsi to understand how to do the extension you suggested. Is this the general design philosophy?: When creating a new table in the CDM, try not to create column names like “air quality”, which will be very project specific. But try to create table with column names like “environment measurement type” + “environment measurement value”, then create an “environment measurement” vocabulary to hold words like “air quality”, “temperature” and etc, which will be used to populate the “environment measurement type” columns. Is this the suggested way?
How you name the columns depends on how you expect to use the table. But, this is no longer OHDSI design philosophy, just general database design. OHDSI tries to be generic because the tables apply to a lot of different sites, but If the only data you are recording in your table is “air quality” then “air quality” would be better then trying to create a more generic table with names like like “environment measurement type” + “environment measurement value”. Design your table to meet you current needs. Later, if the requirements change, you can change your table.
Thank you! That’s a great reminder. We should avoid overthinking and over engineering.