Author: Novarum DX
mHealth is a well-known industry buzzword these days, with both the clinical and commercial community looking to maximise the opportunities inherent in this fast-growing sector.
Many different factors affect the likely commercial success of new mHealth offerings, and while some product development aspects of bringing a new app to market are the same as in any sector – there are some elements that anyone embarking upon a new mHealth initiative should keep front of mind:
1. Is it “actionable”?
It seems obvious that measuring a biomarker or other indicator is only worth doing if there is some action the patient (or those who care for them) can take to change the potential outcome. Good mHealth solutions not only track and record information but help patients, or clinicians, take actions to improve the situation. Actions that the user can perform themselves are more useful than actions that require the intervention of others.
2. Who will pay?
Often in software development the question of who pays is ignored in the early stages. We have seen Twitter, Facebook and others become hugely successful on the back of business plans that largely ignored initial profit maximisation. Almost without exception, those products are now funded by advertising revenues which may not be at all appropriate for privacy sensitive medical applications.
It can often be challenging to convince a healthcare provider to pay for intangible capabilities like apps. While in many countries the patient will not be accustomed to paying for treatments directly and may be reluctant to make a regular commitment.
Of course, a solution that reduces insurance premiums may be tempting for individuals, or an insurer might see sufficient cost savings to fund it themselves – if the right quantitative outcome data is in place. It is important to understand though, that just because it is a great idea doesn’t mean it will make money in healthcare.
3. Beware of making the professional’s life harder
mHealth apps are most widely adopted when clinicians and professionals recommend them. Even if they aren’t the primary user, give consideration to how your product will make their life better, and bear in mind that extra data often requires more time for each patient – not necessarily a bonus for busy clinicians trying to see as many people as possible. Tools which identify the highest risk patients, or process large quantities of data to make quick, robust and effective decisions can help these key people become product advocates.
4. Be clear about privacy from day 1
If any part of your product model requires sharing data with others, be 100 per cent clear about this: make it obvious who will see what. People are concerned about privacy – but they are mostly concerned about the unknown – so be upfront, transparent and succinct, don’t hide it in pages of small print. It is all too easy to lose the trust of your users if you appear to do anything with the data they were not aware of.
5. Don’t forget the Minimum Viable Product
The Minimum Viable Product is a concept widely used in software to help get a product to market quickly, get feedback and make iterative improvements.
The regulatory complexities in medical software can sometimes discourage people from using this approach, as it can create a huge list of demands from potential users.
Trying to develop and deliver a complex solution that addresses these straight away will almost guarantee failure: not only will the time to market be delayed, but your users may be confused by the complexity of the offering and struggle to learn its features. Focus on the key aspects that deliver maximum benefit first. Your users will soon tell you what-else they want to see included.
6. Don’t try to build the entire eco-system yourself
There can be a temptation to provide all the systems and functions yourself, but most modern software and services have application programming interfaces (API) allowing you to share data or track activity. By providing your own API you can let others build capabilities on top of your core functions, letting users gain wider functionality without getting involved in every niche application.
7. Make sure the solution exploits the best of mobile
Mobility means that users will expect your solution to function without an Internet connection. Users also appreciate it when sensors offer functionality not available on their desktop computer to either enhance usability or provide functions simply not possible from a traditional computer – like augmented reality, barcode scanning, etc.
Embarking upon an mHealth initiative?
For more information about developing a mHealth strategy visit make an enquiry below: