As the app industry grows—current estimates are that downloads will reach nearly 270 billion by 2017—the opportunity for the medical device industry to create healthcare apps is vast.1 Yet, while these apps offer the potential to improve the complex world of healthcare, they can present many challenges related to safety, security and privacy issues. These themes are prevalent for all software and apps, but they are critical in the field of healthcare.
Whether or not they are related to healthcare, nearly all apps contain data such as names, location tracking and historical data that most people would consider personal. Mobile health apps typically collect data that is much more sensitive, as it contains health readings, monitoring information, diagnoses, medications and vital statistics. Adding to the inherently sensitive nature of the information an mHealth app is data gathering. The Health Insurance Portability and Accountability Act (HIPAA) of 1996 contains specific security rules to assure confidentiality and information protection. One of the largest issues with mHealth apps is keeping personal health data safe and secure.
Devices that have a public interface or use a web server are especially susceptible, as they attract more potential security risks. Often, devices that reside solely within a hospital network are not adequately secured. For example, they may use default or common passwords given the expectation that internal hospital devices will only be used on the internal hospital networks. However, if an attacker is able to exploit employee credentials, he or she may gain unfettered access to all internal systems, which compounds the inherent risk any app has to be compromised.
Planning ahead is a critical step to protecting patient information. First and foremost, consider how your app will collect data, understand what data is needed for your app to function, and limit the data you collect to essential information. Then, determine which data, if any, will be shared with external servers and which will stay on the device. Also, consider what will happen as your app is updated in the future. Be prepared to wipe data that is no longer needed from both the device and external servers. Limiting data as you collect and store it will limit exposure and reduce the threat of breaches.
Whenever possible, plan to store all data without user-identifiable information. Instead, assign users unique identifiers that do not directly link to personal information. This safeguard helps to ensure that if someone gains access to a unique identifier, this person cannot access information in the app. Using defensive programming strategies is also an important process that all medical software should employ as a key mitigation technique for cyber security.
Be prepared to test apps to ensure that they are keeping data secure. Determining vulnerability in data transmission is crucial and will help ensure the security of user data while being HIPAA compliant. HIPAA is very concerned with user data, and testing for security and encryption of data at motion as well as at rest are crucial to the development process. It is important to test how the data is being sent from origin to destination and utilize encryption algorithms to handle data.
As seen recently, no amount of testing can keep software immune to attacks. However the right kind of security testing and protection can make an app less susceptible, in turn keeping user information and brand reputation safe. Having security built into the app itself is one of the most effective ways to keep an app HIPAA compliant and safe from attacks.
In addition to considering what information an app will gather, developers must also consider how to handle the data that is collected. This is where in-app security comes into play. Whether through PINs, passwords, or timeout features, it is imperative that methods are employed to the need for user control, security and interaction.
There is a fine balance between security and usability. It is important to develop an app with the user in mind, while also ensuring security isn’t being sacrificed. Understand how users will interact with software. Doing so will make securing function easier. For example, while an app may allow for a four-digit PIN to access data, having a lockout for entering the wrong PIN more than five times should deny further access. Allowing an infinite number of tries could allow an attacker to exploit the intended safety feature of a PIN to try numerous combinations. The balance here is a minimal inconvenience to the user with five attempts, while limiting unauthorized access.
Allowing users to manage their data however they choose is a key benefit in mHealth apps. For any sensitive information, give users the opportunity to agree to its use at all. For example, many general apps inform a user when they want to use current locations, and users can elect not to share that information. Users should be able to categorize and delete data without concerns that the data will reappear elsewhere or be stored. Likewise, users should have to the option to opt out of data collection or sharing altogether. In general, companies should take the default stance that users do not want to share data with anyone but a healthcare provider. Taking this approach will ensure that any information shared is explicitly approved by the user.
It is important to consider how to handle data that is collected. User data should not be sent off a device, unless absolutely necessary, and secure channels such as SSL/TLS should be used. Defensive coding also helps limit the damage a user can inflict by using mechanisms that account for negative inputs and providing a predictable response. Encrypting data is also good practice in securing information, as is the use of hash values, instead of Mobile Equipment Identifiers (MEID) or International Mobile Equipment Identifiers (IMEI) numbers. Two-factor authentication is especially useful for sensitive information like medical data. Finally, testing to ensure an app isn’t logging data inappropriately without the user’s or developer’s knowledge can address any final security concerns.
Issues may arise when health and wellness apps interact with other apps on the same device. Make sure you employ safeguards to protect your app from other apps that may communicate with it and use the information stored there. This is particularly important, because you cannot account for the security of other apps once it might pull sensitive information. Weak policies regarding on-device sharing can make an app susceptible to hacking or stolen data. Part of protecting the data in your app comes with the creation of a sound privacy policy.
In light of HIPAA requirements, developers and manufacturers need to have a clear privacy policy in any mHealth app that they develop. In general, a sound privacy policy is a requirement for any app by every platform, operator or app store. A privacy policy should not be general or vague; rather it should be clear, concise and specific. A sound privacy policy will tell users what data is being collected, how it will be used, and with whom (if anyone) it will be shared.
Transparency is critical in any privacy policy, so it is important not to hide behind hard-to-understand legal language or deceptive information. Along these lines, this is not the place to dump objectionable language in the hopes that users won’t see it. Instead, the privacy policy presents the opportunity to responsibly inform users how a company and its app operate.
In the past, some development companies have simply repurposed privacy policies they felt were well-written, whether for different products, brands or even companies. A privacy policy is meant to outline how you use a user’s data that is collected within the specific application. If you are simply repurposing or copying from another app, it calls into question whether you actually have a privacy policy and adhere to the rules of protecting user data. In generally, no two application are exactly the same; therefore it should be extremely rare for one policy to apply to another app. It is worthwhile to put the time and effort into developing a policy that specifically pertains to a specific mHealth app and its associated needs.
A good mHealth privacy policy will do everything a sound privacy policy in general does (as outlined above), while addressing issues particular to the data the app is collecting—whether that be vital statistics, readings or medication information. Information about data sharing and how the app may interact with other programs and apps should also appear in the privacy policy with specific information and guidelines that apply to that app.
Because the apps in question are destined to handle sensitive data and are subject to additional layers of legal requirements such as HIPAA, it is important for developers and manufacturers to employ best practices for continuing to protect patient privacy. In addition to the steps outlined above, some general practices throughout the app development process can also assist in developing a successful app versus a failed one:
As the number of mobile health apps continues to grow, concerns about privacy, safety and security are at the forefront of many minds, including patients, healthcare providers, regulators, developers and manufacturers. Taking the extra steps from the start to ensure an app’s overall security and privacy standards are in place can help alleviate those concerns and pave the way for successful app development, creation and success in the market place.