Data Study on Obesity and Health in NYC
The skills the author demoed here can be learned through taking Data Science with Machine Learning bootcamp with NYC Data Science Academy.
Contributed by Christopher Redino. Christopher is currently in the NYC Data Science Academy 12 week full time Data Science Bootcamp program taking place between January 11th to April 1st, 2016. This post is based on his second class project - R Shiny(due on the 4th week of the program).
Motivation
The World Health Organization lists obesity as one of the leading causes of preventable death worldwide. Although genetics play a role in the likelihood of obesity in an individual, lifestyle (by choice or otherwise) is also an important factor that cannot be ignored. The New York City Department of Health and Mental Hygiene conducts an annual Community Health Survey (CHS) wherein they collect data on a variety of health factors from thousands of New Yorkers in all five boroughs.
Some of this data was used to create an app to visualize how large an effect our geography has on obesity rates, even on a scale as small as the span of a few miles between neighborhoods in NYC. The app can be found here.
Which geographic factors are causing this difference in rates is somewhat an open question: is the availability of fresh food more important, or the median income of residents in a particular neighborhood? In addition to visually exploring the survey data, the app allows the user to explore the effect of different types of food vendors on the obesity rate of different neighborhoods.
Using the App
The first view of the app is of two maps of New York City. The top map visualizes data from the CHS survey, showing the obesity rate (fraction of individuals that are obese) in different neighborhoods. The bottom map shows the results of a simple model, intended to predict the top map.
The input for the model in the lower map is the number of food vendors in different categories (fast-food, pizza, etc) in those same neighborhood regions. The rough idea here is that more vendors of a particular food type may have an impact on the obesity of individuals in that neighborhood. The scales used for both plots are identical, so that the same shade of red in both plots means the same obesity rate. Below the two maps the "Size of Study" is also displayed, which just shows the total number of individuals in the survey used to generate the upper plot.
Side Bar
The side bar for the app serves two functions, to navigate to other tabs, and also to change the input data (by sub-setting it). The check boxes listed under "Sample" in the sidebar will subset the survey data, so you can see explore the relationship between BMI and a few different demographic factors (age, sex, race). Changing the sample will update both maps, and the number of individuals now used to generate the maps will be reflected in the "Size of Sample" displayed at the bottom.
The check boxes listed under "Predictors" will subset the categories of food vendor used to make the model which generates the lower map. For example, if you only want to see how well the number of pizza restaurants predicts BMI, then uncheck all the predictor boxes other than "pizza".
As an additional option there is a radio button below all the check boxes listed under "Predictor Scaling". By default, there is no scaling and the model that generates the lower map only considers the number of restaurants in each neighborhood, but we can instead check "Scale by Area" in which case it is the number of restaurants per square mile that is considered.
Tabs
The other tabs give some other information about the data. Instead of just looking at the obesity rate, we can look at the distribution of the BMI. The "Distribution Full" tab shows the distribution of BMI over all the boroughs in aggregate. The vertical axis shows the actual count of individuals from the survey that fall into each range of BMI, with the obese and non-obese groups colored differently. The reason there is a column with both colors is simply a result of the binning, that is to say, that column shows a range that spans values both greater and lower than 30.
Distribution Tab
The "Distributions" tab is much the same as the "Distribution Full" tab, except it shows a separate distribution for each of the neighborhood regions considered in the survey. You'll notice that the labels for these regions are not something obvious like "Midtown-East" or "Zip Code 10013", and this is because of the way the survey data was collected, which is made a little more transparent in the last two tabs.
Data Tab
The "Data" tab shows both the survey data that is currently being used to generate the upper map (after sub-setting) and also shows the the counts of food vendors of each type (or the counts per area if that option has been toggled). Each row is a different zip code, but you'll notice many zip codes have repeated data, and the only real differences are between rows with a different "uhf", which are the 42 neighborhoods used for the study as identified by the United Health Fund and each can contain multiple zip codes. The final tab, "Reference" shows a map of where these UHF neighborhoods are.
The Data
The NYC Community Health Survey data is publicly available at their website, and the 2013 data is what is used for this app. The data consists of a large variety of self reported health indicators from a little over 8,000 New Yorkers. While there are many health indicators that could have been studied here, the app only focuses on body mass index (BMI). BMI is determined based on the self reported heights and weights of surveyed individuals. An individual with a BMI greater than 30 is considered obsese.
While obesity has clear connections to health problems, BMI is not considered the best way to determine if an individual is obese. Among other reasons, BMI is a bit naive in that it is an attempt to categorize the diversity of all human body types with only two parameters (height and weight), and it does not differentiate between weight from muscle and weight from fat. Acknowledging these shortcomings, BMI is at least a relatively quick and easy way to estimate if an individual is obese, especially if this estimate is to come from self reported data.
In addition to the BMI, the app also makes use of some of the demographic data from the survey, including age group, sex and race.
Other Data
The other data required for the app is the number of food vendors by category in each neighborhood, which is provided by the NYC health inspection data available at NYC Open Data. The actual health inspection data itself is not useful, but the data set contains a list of restaurants with categories, and zip codes, and since the inspections are required annually the data set can be subset to get just those restaurants that were present in NYC in 2013 (at the time of the health survey).
Building the App
The basic work flow to build this app was relatively straight forward once there was a clear idea of what the finished product should look like. First, all the plots, maps and tables for the app are generated in R. Next, all these images are put into a static Shiny app, using the default Shiny Dashboard, which is then tweaked so the style looks right. After the static app has the right aesthetic, all of the interactive buttons are put in place, and finally, the actual interactivity is implemented by introducing reactive expressions into the R script.
The devil, of course, is in the details. One major difficult in creating this app was dealing with the location data, which was necessary to draw the maps. While the health inspection data for restaurants provides zip codes, the health survey data only specified locations by their UHF code. The groups of zip codes that correspond to each of the UHF regions had to be determined manually (by staring at maps) and even then there are still some issues and the process isn't perfect.
The borders of UHF regions don't correspond exactly to zip code borders, but also, if one zooms in on the map, they may notice grey regions with no data, which can happen for a few different reasons. Some of these zip codes do not actually have any residents of their own, examples of these are LaGuardia Airport and Penn Station. Also, the zip code borders' polygons which are needed to generate the maps, are for the current zip codes of NYC, which includes zip codes that did not exist in 2013.
Issues
Another issue worth mentioning is that the reactive expressions needed for this app are a bit more complicated than most of the examples found in the Shiny's example gallery. While the example gallery is a very useful resource when building your first Shiny app, it only provides simple examples. The reason the reactive expression here is more complicated is because the data is reshaped a great deal between when the user provides input (clicking check boxes) and when the output is displayed (the map is redrawn).
The way this is handled is by having the reactive expression return a list in R. Lists are useful for this task because every element of a list can be a different type. The amount of code within the reactive expression should try to be minimized because this will run every time the inputs are changed, and a larger reactive expression will slow down the app.
Data Results
The purpose of the app is simply to explore what factors are involved in BMI. Even without playing with the input, the default map using the entire data set shows that geography has a huge impact on the obesity rates (as determined by BMI) of New Yorkers. Playing with the sample inputs can show how these factors very with various demographic info.
While the bottom map is a "predicted" result, it is also meant solely for exploratory purposes. The map is generated from a multiple linear regression, with the food vendor counts as predictors, and the obesity rate as the predicted quantity, but at no point was it justified that a linear model is suitable for a serious prediction, which is why the only result reported is just the color on the map. Because the scales on the maps are the same, two maps with similar shading would indicate that this crude model is doing an okay job, and picking the set of predictors that best match a given demographics is sort of a game.
In this way, the "goal" of the app is not to provide an accurate model, but rather model exploration is itself the goal; to get people to start thinking about how geographic factors effect obesity and health in general.
Conclusion
If revisited later, it should be relatively straight forward expand this app to include an exploration of factors affecting diabetes as well, as this data already exists in the survey used. A more challenging expansion to the app would be to include predictors other than food vendors, such as income or housing data, or data on the gyms, dance studios or other businesses that promote fitness. The app clearly demonstrates that there are geographic factors affecting our health, but hopefully it should also demonstrate to the user that the problem of understanding these factors is more complex that what can be modeled by simply counting restaurants.
About Author
