What to do when your mHealth app goes wrong
In our last Tech Talk of the year, Dr Neil Polwart, Novarum founder and BBI Group head of mobile, discusses how to mitigate risks for mHealth apps.
Mobile health (mHealth) apps can often bring with them potential risks that are overlooked, but unlike traditional pharmaceutical products, they can also engineer solutions to mitigate product risks.
All medical device software is categorised according to its potential to cause patients harm.
Generally, the greatest perceived risk arises from fundamental algorithm issues which should be subject to the most scrutiny and validation during development.
However, developing robust underlying science is only the start of providing a useful and valuable mHealth solution. How your software handles errors, as with how your organisation handles software failures can be the difference that makes or breaks your offering.
Notice the distinction between errors and failures; we expect errors such as invalid user data and lost internet connections, but all these issues can be managed by good software design.
Software failures happen when we either encounter an error the system was not designed to cope with, or the system design is simply inadequate for the job it is being asked to do.
However, for most users, ordinary bugs like a button not appearing on the screen can be the most frustrating and common, compared to major things such as security breaches.
Ideally those issues would be detected before you go to market. However, with an ever-increasing range of hardware to test on, covering every eventuality with physical testing is a herculean task.
It is almost inevitable that an issue with your software will occur, requiring you to release a new version. Fortunately, your software team will be very familiar with such regression issues and will hopefully have created a suite of tests to help spot the issue before your new version gets released.
These, together with an array of tests run on each individual software component every time the software gets built, integration testing to ensure it is all put together correctly as well as frequent code reviews by different developers should all help to spot and prevent problematic code from reaching the market.
Good mHealth apps will include a mechanism for managing app versions. In some cases, the operating system, app stores or mobile device management software running on all of a hospital’s devices might do this for you, but it is such a critical part of managing software failures that it usually makes sense for the app to be able to check it is up-to-date and alert the user if not.
If your app relies heavily on the device hardware, you may even check if the app is running on an approved list of devices and either warn or prevent the user from proceeding depending on the associated risk.
Together with a programme of frequent maintenance, gathering user feedback and responding to it, you may think these issues will ensure that disaster is avoided.
That overlooks the biggest source of failure in any software product though – the user. You will often have conducted usability trials, perhaps ensuring that the workflow is logical, watching users operate the app and that the expected behaviour is intuitive. You may even have integrated some analytics to identify problem areas in the app and maximise usage.
One overlooked area is that most users want a simple “good” or “bad” type outcome, but of course health is rarely so black and white. Naturally, humans are bad at quantifying risk and understanding probability, so even when results are presented as percentages or odds they may not be well understood.
Some recent mHealth headlines have been made not necessarily by any failure of the app, but rather by a failure to communicate the risk and significance of the data presented – issues such as this can be managed through well thought out user studies at an early stage.