mHealth apps are mobile applications which utilise the ubiquity, connectivity and flexibility of our smartphones to improve patient’s health.
The health conditions, diseases and disorders which benefit from support in this category are diverse and varied, but the common thread that links most mHealth apps is that they collect, accrue and transport data. Data which can then be leveraged to deliver better care, support better behaviours, increase motivation and drive patient action through engagement.
However, this data is personal, it is medical and in some cases it could be personally identifiable, all of which means that data transport security should be the primary focus for any mHealth application in development.
So how do you safeguard patient and healthcare professional data? Let’s find out.
Insufficient transport security has the potential to create confidentiality and safety issues for patients, and as such, mHealth apps need to ensure that security-by-design is addressed to protect data integrity and patient security.
To allow patients to provide information via a mobile application, the application will likely enable the transmission of data to the service provider via communication with servers. Without the most robust transport layer security (TLS) nefarious agents could access the sensitive data entered and transported, which could impact the integrity of the data or in some cases lead to hackers stealing enough personal information to impersonate patients.
However, relying merely on TLS settings can also open the door to man-in-the-middle attacks, so our teams regularly recommend encrypting data in transit alongside leveraging certificate pinning to ensure personal medical data is as safe as possible.
In a 2018 study by Virginia Commonwealth University that reviewed security procedures for mHealth apps relating to mental health and wellbeing found that:
“The majority of apps reviewed were not sufficiently transparent with information regarding data security. (These) apps have great potential to scale mental health resources, providing resources to people unable or reluctant to access traditional face-to-face care, or as an adjunct to treatment. However, if they are to be a reasonable resource, they must be safe, secure, and responsible with patient data.”
So not only were users or patients not fully informed around what data was being collected, but many apps didn’t have the requisite privacy policies, data security processes and transparency around their data handling and storage practices.
In a highly regulated industry like healthcare, this simply is not ok. mHealth apps need security to be their primary feature.
If mHealth apps are to create the kind of scalable access to services, assistance and care that their creators purport, then they have to adopt a security-first design methodology that ensures that the most robust, modern data security practices are adhered to.
mHealth apps can provide scalable solutions to real healthcare challenges, but if they are to be seen as a suitable option for those habituated to face-to-face care then security should be the defining USP.
Just as healthcare professionals are held to the most rigorous standards of practice, methodology and confidentiality, so should the mobile applications that aim to be a supportive resource to these professionals.
Codifying and formalising such standards will not only increase patient confidence but also raise the likelihood that clinicians and other healthcare professionals will recommend mHealth apps to patients.
By being transparent about how data is collected, transported, stored and used, a dialogue can be generated between patient and healthcare professional to detail the exchange of value that creates benefit across a patient’s wellness journey.
Here at Waracle, we have been building mobile applications since the advent of the iPhone, so we know a thing or two about mobile app security. If you have an existing solution that needs reviewing or if you are building a mHealth solution from scratch, our team would love to hear from you.