Initial Project Goal – Build an open source, web based, geo-enabled health data mapping & visualization tool to aggregate disparate public health data from multiple sources and make it cool for everyday folks to experience that data in a locally meaningful way.
Revised Project Goal – Build an open source, web based, geo-enabled health data platform/API including a location specific take action database and couple that platform with some proof of concept prototype front ends for specific use cases including real estate, healthcare, journalism, personal health, and community health/engagement.
1) Understand the Opportunity - One of the things that made this project unique is that we are not health experts, in fact if you consider how much pizza, soda and beer we consume and how little sleep we get, we are probably about as far from health experts as you can get. But we are open data and open source experts with diverse experience creating very innovative software solutions. So the combination gave us a very unique perspective. The world of health and healthcare is a huge complex labyrinth, so we made it a priority to better understand the real opportunity beyond just saying, “Wouldn’t it be cool if…?” Much of our work to understand the opportunity focused on human centered design(HCD) techniques. We conducted a stakeholder mapping exercise. We spoke with all kinds of folks about this opportunity including physicians, public health officials, demographers, elected officials and community leaders. We created an assortment of personas representing various user types and/or use cases. We also did traditional research to understand what research and technology already existed in this space along with identification of where other organizations were headed.
2) Understand the Users – To maximize impact we also wanted to obtain a better understanding of potential users. Why would a user want to use our app? What would make it compelling? Who would want to use it? Once again we were able to use HCD techniques to explore user types and ultimately generate a better understanding of and empathy for our likely users. We were fortunate in this respect because much of the inspiration for our project came from Sunlight’s Sitegeist App. Sitegeist is a first of its kind mobile app that uses a device’s GPS to identify and display location specific high resolution census and related data. Because Sitegeist was a well-developed fully functioning app we were able to use it as a sort of surrogate for our project. In this light, we had a distinct advantage because we had an actual app that we could show people at the start of our project. Using this surrogate as a stand in for our proposed app allowed us to better understand users and how they might relate to our project.
3) Build a Prototype – People can talk, analyze, engineer, and brainstorm but at some point there are certain things that can only be learned by doing. With a limited budget and resources we still made it a priority to build a real working prototype for this project. As we learned more about the opportunity, potential users, and use cases, the vision to build a single app to serve as our prototype gave way to the need to build a platform/API along with various prototype front ends to the data.
What we learned:
1) Huge opportunity – The biggest lesson we learned is that this opportunity is much, much bigger than we ever imagined. America’s health is facing some daunting challenges and wide scale awareness and understanding that health outcomes are more about health than healthcare is crucial to improving America’s health. Our blog post, Shouting from Rooftops addresses this in greater detail.
2) Data is not enough – Probably the most valuable lesson we learned is that location specific data is not compelling enough by itself. We had initially fallen into a “wow, isn’t this cool” technology trap. The Sitegeist App was instrumental in revealing this since we were able to use it to observe how people experience hyper local data. Once users got beyond the gee-whiz factor of the app, they weren’t really sure what the ultimate purpose for the data was. People wanted to be able to take some type of action with the data. Some of the ways people wanted to take action were to alert the media, notify elected officials, find resources that could help them, or learn about ways they could help themselves.
3) Be sensitive to user’s situation – We learned that simply aggregating lots of raw data about an area was not enough. Many use cases benefited from scoring or grading the data in some way. Scoring or grading works well until we considered the people who live in neighborhoods with low/poor scores. Is this a fair thing to do to them? Are there better ways to score the data so we don’t adversely impact an area or the people in that area? Significant work went into the trade-offs here, and still more work needs to be done.
4) It’s a platform not an app – When we started this project we thought we were building something similar to Sunlight Foundation’s Sitegeist App. The idea was that we would aggregate all kinds of disparate health data and then build one app that is a fun intuitive interface to display location specific data on mobile devices. After all of our efforts to understand the opportunity and the potential users, we realized that one app was not going to work for everyone.
What we built:
1) Backend API – We built an open source PostgreSQL. PostGIS, GeoDjango database backend with a RESTful API that serves as a data store for all of our aggregated data. Multiple disparate data sources were identified, aggregated, imported, geo-coded and stored in this system. Additionally, we built a model for intelligently combining these data elements into various “buckets” of data using the healthypeople.gov model for Social Determinants of Health(SDOH).
2) Take Action Database – We built a location specific Take Action Database that aggregates location specific ways for people to take action based on the data they are experiencing. Some of the geo-located ways to take action include Data to the Editor, Elected Official Finder, Program/Resource Locator, and our Healthy Tomorrow Knowledge Base.
3) Real Estate Data Explorer – Our Real Estate Data Explorer prototype allows individuals to view the health of a neighborhood to assist in home selection and comparison.
4) Personal Health Explorer – Our Personal Health Explorer prototype allows individuals to identify the top actionable health risks in their area. It also connects them with programs and resources which allow them to offset those risk factors through our Take Action Database.
5) Community Health Explorer – Our Community Health Explorer prototype allows community minded individuals and organizations to identify and prioritize the biggest community health challenges in an area.
6) Health Reporter Tool – Our prototype Health Reporter Tool allows journalists to explore health data for an area with an eye on health disparities, opportunities and outliers. During our project we discovered and became big fans of censusreporter.org. We developed a very basic wide area map view prototype as our Health Reporter Tool. We anticipate a more sophisticated interface in the future similar to CensusReporter.org’s approach.
7) Clinical Care Tool – Our prototype Clinical Care Tool was designed to present data in a clinical care environment that shows health professionals area specific health risks for a specific patent. Current approaches to healthcare do not specifically include location specific risks in patient care and treatment.
8) Wearable Health Data Explorer – We built a prototype wearable wristband with LED indicators that show the health data for an area. Red for below average, yellow for average, and green for above average. The LED indicators update in real time as someone explores a city. The wristband was designed and built in house and uses Bluetooth Low Energy to wirelessly communicate with an iOS iPhone App that queries our health data API. The iOS app has sophisticated logic that monitors your movements and only updates the data when you move out of the current data boundary this was implemented to save battery life. The iOS App also allows the user to select what data is sent to the wristband.
Where we are headed:
Now that we have a basic platform and some prototype front ends to the data there are a few logical parallel paths moving forward:
1) Statistical Correlation Modeling – We learned fairly quickly that people get overwhelmed by data overload when viewing raw data. The most user friendly way to handle this is to score the data, scoring options include number scores, letter grades, color codes etc. Transitioning from presenting raw data to scored data requires statistical correlation modeling to properly score and weight data. Additionally some of our data modeling involve summing or averaging multiple data points into one score or data “bucket”. We hope to develop some more sophisticated algorithms for accurately scoring and weighting both raw data and data in these “buckets”.
2) Small Area Estimation Models – In certain cases the available resolution for some of the data we identified is less than optimal. We see an opportunity to develop some small area estimation models to increase the spatial resolution of the data for better location specific data targeting. Since we are already aggregating high resolution census, population and demographic data it should be relatively straight forward to automate the process of modeling/estimating some of the lower resolution data at higher geographic resolutions.
3) Partnerships – We learned a lot about this opportunity and built an amazing platform and some very impressive front ends to our data. We also realized that if we want to maximize our impact we need to partner with community health orgs and some of the other folks that are already trying to be impactful in their own way. Some of the orgs we are targeting include the World Health Organization, the Robert Wood Johnson Foundation, Healthypeople.gov, and Esther Dyson’s Hiccup.co.
4) Platform Improvements – The platform we built is a great starting place but we see lots of opportunity to improve it. One of the features we knew we needed but had to cut from the feature list based on time and budget constraints is multi-year data tracking. We want to be able to index and track data by year which will allow us to show directional data trends which in and amongst themselves could prove to be immensely valuable for identifying growing community health problems. We also see an opportunity to expand the API Query rules to give greater flexibility in API usage. In addition we hope to add some intelligent location matching to provide comparative location matching and analysis.
5) Expand Data Coverage – Due to the limited budget and time frame for this project, we only looked at data for Oklahoma/Northeastern Oklahoma. In addition, we did not have the time or budget to include all of the data that we identified. So we used a reasonable sampling of data to demonstrate the overall concept and vision. We want to complete the aggregation of the remaining data for Oklahoma and then select two more states to focus on. By using a few more stated to get the kinks worked out, we see a big opportunity to eventually include data for the entire U.S. and beyond.
In conclusion we believe we have developed a ground breaking platform that will give individuals, organizations and governments the ability to solve some potentially huge challenges related to health. So are you an individual, organization or government? Do you have thoughts on intelligent and creative ways to use the HealthAround.Me platform to solve local health challenges? As we push this project forward we want to partner with you and other folks to help solve local health problems. Feel free to reach out to us at email@example.com.