The developers of the app Pain Care, the winner of the Robert Wood Johnson Foundation’s Project Health Design challenge two years ago, have this to say about THCB contributing writer Dr. Leslie Kernisan’s recent post wondering why the winning entries of development challenges have a habit of disappearing and never being heard from again:
We are the app developer. We are also disappointed with the outcome of the app. But I think we also learned valuable lessons here.
One of the challenges small business facing is the need to rapid prototype and test the market, and then move on to another idea when the previous idea fails to gain traction. That is especially true with grant funded projects — they need to “make money” after the grant ends in order to justify continued development effort.
Pain Care was developed in the early days of mHealth, and it was indeed very physician focused — the reason is that we believe we must engage physicians to look at the data. We still hold that belief. It is a learning process for us. We put in our own money to develop the app, and fortunately, won the developer challenge.
We made the app public after the challenge to “test the market” — so to speak. But, as you know, essentially *none* of the pure app-based “patient journal” has turned out to be a success (let alone a financial success). Our app is no exception. It is enormously costly keep the app updated for all those iPhone, iPad, iOS released every year, as well as thousands of Android devices released since then.
So, the app becomes one of those “outdated” apps in the app store, and I think it is quite obvious to users as well. However, I think the app did contribute significantly to the “science” of mHealth. We now understand much more what works and what not in “patient engagement”. Many other “pain management” apps have since emerged, and many have done a better job than ours. I think that was what RWJF wanted when they challenged developers back then.
Today, we do things a lot differently. We no longer release research grant-funded apps to the public. Instead, we run clinical studies to test them in much smaller / controlled groups. We do not attempt to tackle vague “big problems” like general pain management any more — instead, we are much more focused on managing specific diseases that include pain. We are also moving beyond “pure software” and “simple reminders” to engage people in multiple modalities.
All of these would not be possible without the generous award RWJF gave us in picking Pain Care as the winner of one of the first developer challenges.
Categories: Uncategorized
This is a very helpful perspective. The Division I work in at ONC sponsors many Challenges. I think a common misconception is that the primary intended outcome of Challenges is for the winning application to turn directly into a successful business. This perspective is usually held by people who have never actually worked in a startup or brought software to market. Anybody who has knows that a few weeks in you are just barely beginning to understand the problem and what you should build.
A few of the other many reasons we sponsor Challenges:
1. To attract talented entrepreneurs and developers to the healthcare field.
2. To bring their attention to a high priority patient population or other software/app use case.
3. To get devs playing with new data or important standards for data transport that they may not be aware of, especially if not coming from a health IT/informatics background.
4. To create a structured experience that encourages developers, clinicians, and patients to work together. See the ONC’s recent Patient CoDesign Challenge.