The Million Hearts Risk Check Challenge

About the Challenge

Challenge Background

Are you at risk for heart attack and stroke? Are your loved ones? If you are like many Americans, these thoughts have crossed your mind, only to be replaced by the demands of the day and often returning in quiet moments. In communities across America, there are thousands of convenient and inexpensive ways to know your risk for heart-related conditions. Often, all it takes is scheduling a screening with your doctor or at a pharmacy. However, nearly 15% of people at risk for cardiovascular disease (CVD) are undiagnosed and less likely to take preventive action.

Million HeartsTM and the Office of the National Coordinator for Health IT (ONC) are sponsoring a developer challenge and outreach initiative to inform millions of Americans who may be unaware they are at significant risk for CVD , encourage those who think they may be at risk to take action, and direct both to  community pharmacies to receive blood pressure and cholesterol screenings. Million Hearts and ONC seek to replace ignorance, worry, and inaction with knowledge, empowerment, and a means for referral.

The outreach initiative and winning app will:

1. Reach individuals across the country, taking special aim at those who may be at risk for CVD and don’t know it.
2. Deploy an engaging user interface that provides consumers with a quick health risk assessment, motivate them to obtain a more accurate risk assessment by entering their blood pressure and cholesterol values, and
3. Direct them to nearby community pharmacies offering affordable and convenient blood pressure and cholesterol screenings.

This initiative will be a part of the Million HeartsTM initiative, a public-private partnership led by CMS and CDC to prevent a million heart attacks and strokes by 2017, and will be executed by Million Hearts partner organizations and others aligned with its aims.  Initially, four cities – Chicago, Baltimore, San Diego, and Tulsa – will aggressively promote consumer participation in the initiative, and it will subsequently be rolled out nationally.

The purpose of the campaigns (and the new consumer app developed through this challenge) is threefold. Developers should keep these purposes in mind throughout the development process:

1. Encourage further testing (specifically blood pressure and cholesterol), especially for those with some risk,
2. Encourage lifestyle changes for those at some risk, and
3. Encourage seeing a health professional if they are at high risk. 

Challenge Description

This challenge grant asks developers to create a new consumer app that informs consumers of their general heart risk, motivates them to obtain a more accurate risk assessment by entering their blood pressure and cholesterol values, and directs them to nearby community pharmacies (and other locations) offering affordable and convenient blood pressure and cholesterol screenings.

Participating developers will have access to two sources of content that should markedly shape the development of the app:

1. A new Application Programming Interface (API) for conducting the quick health risk assessment over a consumer-facing interface, hosted by Archimedes and built using their Indigo product.
2. Locations (and specific descriptors) of places where individuals can go for a lipid and blood pressure screening, made available through flat files from Million HeartsTM  and a new API hosted by Surescripts.

Each of these source APIs are described in more detail below and in linked appendices. In order for the Department of Health and Human Services to formally “sponsor” the winning app in a Million HeartsTM campaign, it will be important for applicants to specifically follow the inputs and outputs of the two APIs. Conformity with these inputs and outputs is included in the judging criteria.

Aside from these API elements, creativity is strongly encouraged, particularly in platform design, consumer engagement, personalized risk communication, and ways to link the two APIs together. More information about the judging criteria appears below.

 Eight Question Health Risk Assessment Content

The app should begin with an eight question  health risk assessment, designed to engage individuals by asking them questions about their personal health. The health risk assessment should launch soon after the consumer launches the app itself. It also must be introduced with an assurance that responses to these questions will be kept private and confidential. Otherwise, it is up to the developers to make the transition into the risk assessment process, and to create a risk assessment process that is engaging.

The app should ask the following eight questions to answer the required inputs of the Archimedes API (see Appendix A and Appendix B):

• Age (18-85 allowed)
• Gender (M,F)
• Height (inches)
• Weight (pounds)
• “Do you currently smoke?” (yes, no)
• Further explanatory text: “Answer yes if you have smoked any cigarettes in the past month”
• “Has a doctor ever told you that you had a heart attack” (yes, no)
• Explanatory text “a heart attack is sometimes called a myocardial infarction or MI"
• “Has a doctor ever told you that you had a stroke” (yes, no)
• “Has a doctor ever told you that you have diabetes” (yes, no)
  • Explanatory text “Answer yes if you have diabetes mellitus type I or type II”

The app should also ask whether the individual has recent data on their blood pressure and cholesterol measurements (biomarker data).  If yes, individuals should be given the opportunity to enter the six values listed below to calculate a more exact risk score:

1. Systolic blood pressure
2. Diastolic blood pressure
3. Total cholesterol
4. HDL Cholesterol
5. LDL Cholesterol
6. HbA1c (IMPORTANT NOTE TO DEVELOPER: this question is asked only if patient says they have diabetes.  HbA1c is typically communicated with one digit after the decimal point.  For example 6.9 or 8.2)

There are then two scenarios:

1. “Get Tested Phase”, ifthe user has not provided blood pressure and lipid data, or only entered some values: the Archimedes API will calculate rough risk estimate and the app should encourage them to obtain testing for the remaining values to enable an accurate estimate of their risk.  This is described in more detail in the “Get Tested Phase” section below.
2. “Risk Calculation Phase”, when the biomarker data has been entered:If the user enters these values, either on the first try or after obtaining testing, then the Archimedes API will calculate their risk and return additional information about options for reducing it. This is described in more detail in the “Risk Calculation Phase” section below.

 “Get Tested Phase”

If the user has not provided blood pressure and lipid data, or only entered some values, the app should

• Give the individual a rough estimate of how high or low the individual’s risk could be, as obtained through the Archimedes API (See Appendix A and Appendix B).
• Indicate that it will follow up with the individual later for the biomarker data.
• Provide them with information on how to obtain their biomarker data (see “Screening Location Mapper” section below).
• Prompt them periodically to complete their risk profile with blood pressure and lipid data.

After the app provides the individual with a rough estimate of his or her possible risk score, it should then transition immediately into convincing the user of the importance of completing the health risk assessment by getting a lipid and blood pressure screening. Apps will be evaluated for creativity and effectiveness in transitioning from communication about risk to communication aimed at persuading the individual to go to a nearby pharmacy for a lipid and blood pressure screening.

Screening Location Mapper

In the case that the user does not enter blood pressure and cholesterol values, after prompting individuals about the importance of a blood pressure and lipid screening, the app should then prompt them to enter their address (or use a device-enabled technology for getting their latitude and longitude such as the iPhone’s “current location” feature).

Based on the user’s latitude and longitude, the app should send individuals the closest locations where they can go for a risk screening (based on developers’ discretion of an appropriate distance and an appropriate number of locations from the user’s location) in a map-like output.

Screening locations will be provided from two sources:

1. A directory of participating pharmacies will be provided by Surescripts. This directory will be accessible to developers via an API, and will remain available for free to the winning app throughout the campaign period. This directory will be updated frequently, and the developer should accommodate these updates by accessing the directory in real time or caching periodically. See Appendix C and Appendix D for specific detail on the API and how to access it. 
2. A directory of participating healthcare providers may be provided by HHS and/or participating “launch cities” (see below). This Community Healthcare Provider directory will be provided as a flat file, which the developers will receive from participating cities and/or HHS. These files may be updated periodically by HHS.  HHS and Health 2.0 will follow-up with developers that register on the website about any updates or additions to this directory. Appendix C, Table 2.2.2.1 shows the format of the files that will be sent to the winner.

Both the flat file(s) and Surescript’s API will make available the same fields of information for each location, as follows (and as described in Appendix C):

1. Name
2. Address1
3. Address2
4. City
5. State
6. Zip
7. Cross Street
8. URL
9. URL Caption
10. Phone number
11. Description (Description of service offered + special offer. E.g., “Total Health Risk Assessment available for $10 if you use this app. Mention code GETSCREENED to receive this special offer.”)
12. Lat (when available)
13. Lon (when available)

Developers should create an app that uses locations from both sources, and which feeds the closest x number of locations (developers’ discretion) back to the individual in a map-like output.

Only locations that offer BOTH a blood pressure reading and lipid screening will be included in the Surescripts API and the flat files.

Follow Up

After connecting individuals with the screening locations, the app should do everything it can to get them to complete the screening. Apps will be judged for their effectiveness in prompting individuals to take this action.

Periodically after connecting individuals to the screening locations, the app should follow-up on whether they have completed their lipid and blood pressure screening.

Once the individuals indicate that they have completed their screening, the app should prompt them to enter the values from the blood pressure and lipid screening. Once the biomarker data has been entered the User is now in the “Risk Calculation Phase.”

“Risk Calculation Phase”

 Once an individual has entered blood pressure and cholesterol measurements, the app may (at app developer’s discretion) ask an additional set of risk questions listed in Appendix A.

The app should then generate and communicate the individual’s risk. The Archimedes API offers a few different options for how to communicate risk (see Appendix A and Appendix B). It is up to the app developer to decide which of these methods to use. Developers should exercise a high degree of flexibility and creativity in figuring out how best to communicate the results of the risk assessment. Whichever method is chosen, it is key that risk information be conveyed, following the outputs offered by the Archimedes API.  Apps will be evaluated for their effectiveness in communicating relative risk to the individual; i.e. how clear and actionable the information is to the end user.

After communicating the risk, the app should provide information about possible approaches to reducing that risk relevant to that individual.  The Archimedes API will provide a series of possible interventions associated and associated risk reduction values, (e.g. “A doctor may be able to lower your risk of cardiovascular disease by x% by reducing  your blood pressure” or “adding three hours of moderate exercise to your weekly schedule could reduce your risk by y%”).  A more complete list of follow-up intervention messages can be found in Appendix A and Appendix B. 

Platform Agnostic

We are not specifying what platform the app should be designed for. However, apps will be evaluated on their ability to:

• Be readily available to a large number of individuals and incorporate diversity (e.g., age, race, income levels, language / cultural sensitivity, disabilities and special needs, etc.)
• Be engaging and easily fit with a large and wide range of individuals’ daily lives.
• Be interactive (e.g., easily allow individuals to have a back-and-forth “conversation” with the app)
• Be easily incorporated into the marketing campaign (e.g., have a clear ‘action’ that could be advertised on a billboard, promoted by community leaders, etc.)

Platforms that could work along these criteria could include – but are not limited to – Facebook, Google+, smartphones, and text messaging.

Review Panel

• Dr. Farzad Mostashari, National Coordinator for Health Information Technology

• Dr. Janet Wright, Executive Director, Million Hearts Initiative
• Bryan Sivak, Chief Technology Officer, HHS

• Dr. Nick Yphantides, Chief Medical Officer, San Diego County

• Mark Headd, Chief Data Officer, City of Philadelphia

• Dr. Jay Miller, Physician Volunteer, Commissioner's Office, Chicago Department of Public Health

• Dr. David Kendrick, Chief Executive Officer, MyHealth Access Network

• Jerrie Kumalah, Assistant for Special Projects, Baltimore City Health Department
• Greg Downing, HHS

• Pierce Graham-Jones, HHS
• William Riley, NIH
• Don Morris, Archimedes
• Rajesh Manglani, SureScripts

Review Criteria

1. How well the apps follow the specific input and output requirements of the two APIs and exchange data with the data sources (Surescripts and the Community Healthcare Provider lists), as well as the Archimedes API
2. Effectiveness in getting individuals to answer all the questions for the initial risk assessment
3. Effectiveness in communicating initial risk to individuals, based on guidelines provided by Archimedes API
4. Effectiveness in encouraging further testing (specifically lipids and BP), especially for those with some risk
5. Effectiveness in communicating final risk to individuals, based on guidelines provided by Archimedes API
6. Effectiveness in encouraging lifestyle changes for those at some risk
7. Effectiveness in encouraging seeing a health professional if they are at high risk
8. How easy and intuitive is the app to use, and how well does it engage consumers from diverse backgrounds. Which app is the most likely to get the most people to know their full cardiovascular risk?
9. Submissions will be judged on their operating plans for the year, and the sustainability of the app over the life of the initiative. Has the entrant provided a viable plan for initial and ongoing technical capacity to meet projected usage as well as for support, maintenance and enhancement of the application?
10. Demonstration of submitter’s current or prior ability to engage consumers.
11. Demonstration of a business plan and likelihood of the app being sustainable beyond the campaign period.

Along with their app submission, entrants must submit a plan for how they will operationalize and sustain their product, and how many users they are capable of supporting throughout the length of a 12-month promotional campaign associated with this product (as described further below).

Although apps are not likely to collect personally identifiable health information, submissions should consider relevant privacy and security issues, laws, and policies, and ensure apps include appropriate privacy and security protections where necessary.

Personal health information will never be shared with HHS or ONC as part of this challenge.

Campaign           

The winning app(s) may be heavily promoted by the Department of Health and Human Services, the Million HeartsTM initiative, and their partners. The initiative will unfold in two stages:

1. Initially, promotional efforts will be focused in five launch cities: Tulsa, Chicago, San Diego, Philadelphia, and Baltimore. The campaigns will be executed by city leadership, with the support of private partners and the federal government, and are planned to include outdoor, radio, and print advertising; grassroots, community-based promotion; highlighting at major events; and highlighting by city and national leaders.
   
   
2. The campaign will subsequently launch nationwide, as a focus of both Million HeartsTM communications and those of Million Hearts national corporate partners.

The Million HeartsTM website will promote the challenge and direct consumers to a landing page that can reroute them to the winning app(s).

Prize

Submissions are due by 11:59 pm et, November 2, 2012.

Up to five finalists of this app challenge will be announced by November 30, 2012. Each of the up to five finalists will receive $5,000.

Between roughly November 19, 2012 and December 31, 2012, up to five finalists will be asked to participate in a testing period. The judges, as well as approximately 200 test users, will try out and evaluate the winning apps. Apps will be expected to be fully operational, using the best available data available to them, during this time. This may require using dummy data.

The grand prize winner of the app challenge will be announced in early January, and will receive an award of $100,000.

Aside from the cash prizes, the winner may receive significant promotional support, as described in the “Campaign” section above.  

Conditions of Participation

By participating in the Developer Challenge and/or entering a submission, all entrants agree to make the grand prize winning app available for free, to all users, until December 31, 2013, including hosting and maintaining the web service in a scalable format, providing updated releases to app stores, responding to requests for technical support, bug fixes, and other reasonable requests from the Department of Health and Human Services, Million Hearts, and its partners.

Submissions must include operating plans for the year, and submissions will be judged for the likelihood of the submitter successfully maintaining the app to support the campaign. Has the entrant provided a viable plan for initial and ongoing technical capacity to meet projected usage as well as for support, maintenance and enhancement of the application? Winning app(s) will be required to report usage statistics to HHS on a regular basis. Developers are encouraged to include plans for the reports they would create.

Submissions must also include business plans that extend beyond the first year, including commercial uses of the application. This could include investor statements. Apps will be judged on the submitter’s demonstration of this business plan and likelihood of the app being sustainable beyond the campaign period.

Submission Requirements

In order for an entry to be eligible to win this Challenge, it must meet the following requirements:

1. General – Contestants must provide continuous access to the app, a detailed description of the app, instructions on how to install and operate the app, and system requirements required to run the app (collectively, “Submission”)
2. Section 508 – Software applications should meet objectives for federal compliance guidelines for information technology. See Section 508 of the Rehabilitation Act of 1973 for more information: http://www.section508.gov. Additional resources can be found at www.hhs.gov/web/508/index.html and www.access-board.gov/508.htm.
3. No HHS or ONC logo – The app must not use HHS’ or ONC’s logos or official seals in the Submission, and must not claim endorsement.
4. Functionality/Accuracy – A Submission may be disqualified if the software application fails to function as expressed in the description provided by the user, or if the software application provides inaccurate or incomplete information.
5. Security – Submissions must be free of malware. Contestant agrees that the ONC may conduct testing on the app to determine whether malware or other security threats may be present. ONC may disqualify the app if, in ONC’s judgment, the app may damage government or others’ equipment or operating environment.

Appendices

Appendix A: Archimedes Indigo API Usage Document - https://docs.google.com/a/health2con.com/file/d/0B-92JGcC6Z1zaUZhemtENmJKa0k/edit

Appendix B: Archimedes Indigo API Data Spec - https://docs.google.com/a/health2con.com/file/d/0B2-BsAvBrc_5ZTZKR2t5VWhPY0E/edit 

Appendix C: Surescripts API Guide - https://docs.google.com/file/d/0B3sVttT1pMhMMGpCLXhlZ2RLU2s/edit

Appendix D: Surescripts API Using the Test Application - https://docs.google.com/file/d/0B3sVttT1pMhMZFdmYTF3Zkhnemc/edit

Appendix E: Flat File Format - https://docs.google.com/a/health2con.com/file/d/0B-92JGcC6Z1zZVVkdjkxLWRXdms/edit