Mobile Medical App Development – Not for the Faint of Heart
Overcoming the Challenges
Mobile devices and the apps that power them have quickly become a part of everyday life. The promise of “anywhere, anytime computing” is now extending to mobile medical apps, bringing a wide range of health information, device connectivity, and data to patients, caregivers, and physicians.
It’s not very difficult to create a mobile app – a number of tools have emerged which can make it pretty straightforward to develop basic functionality for a tablet or phone. A mobile medical app, on the other hand, is considerably more challenging because it involves more than just developing an app. Most medical apps must at least follow FDA or CE Guidance (for example, conformance to 21 CFR Part 820, ISO 13485, and IEC 62304) and some require full 510k regulatory approval. Therefore, mobile medical apps require a more rigorous approach to managing requirements, design, implementation, test, documentation, and overall management of the product. And even for those familiar with these processes, mobile devices present additional challenges.
As a Technical Project Manager who has been managing the development of mobile medical apps for more than four years here at Syncro Medical, I’m writing to share some advice, particularly for companies considering entering this new arena for the first time. While there are many considerations, I want to highlight three in this blog:
- Privacy and security of personal health information
- Continuously changing target OS platforms
- Multiple target devices
Privacy and Security of Personal Health Information
In all of my years of working with or at medical device companies, I have seen increasing concern with HIPAA, privacy, and security of personal health information (PHI). A mobile medical app compounds these concerns since mobile devices create even greater opportunities for illicit access to the user’s health information. The mobile device can get lost or used by other people or wireless data links could become vulnerable. Medical device companies take all of this very seriously, so apps need to protect data and use secure communication. These goals must be addressed from the initial requirements all the way through the development cycle.
Several of my recent projects started with the app storing data in the app’s database instead of the cloud upon initial release. So, we looked at options for encrypting the data. Individual data or database tables can be encrypted. However, in these cases, a sufficient amount of data was considered personal to warrant encrypting the entire database. The encryption key should be unique for every app installation to further protect the data. Of course, all wireless data communication with devices or to services in the cloud with PHI must be encrypted. Finally, for future versions of these apps utilizing cloud storage, the cloud will need to securely store the PHI.
Continuously Changing Target OS Platforms
The target devices for mobile medical apps are the users’ mobile phones or tablets and their ever-changing operating systems (OS). This has a major impact on development and especially testing – a critical aspect of developing regulated apps.
The best way to mitigate this complexity is to limit the range of supported platforms in a way that makes sense for the product. This can be done by choosing which mobile operating system(s) to support, and which versions of those operating system(s).
Although there are a few mobile operating systems available, two are dominant. Worldwide, over 80% of mobile devices now ship with Android and most of the remaining phones ship with iOS. The US market is a bit more evenly balanced with approximately 50% Android and 40% iOS coverage. In addition, Apple and Google release new versions of each OS on a regular basis.
To handle this, several of my clients have started their mobile medical development by focusing on a single operating system, either iOS or Android. This can be a tough choice, although often the choice will be dictated by our clients’ customers and where the app will be released first. In my experience, this initial OS choice results in quicker time to market without limiting future expansion.
The second step in reducing complexity is to decide which version(s) of the chosen operating system(s) the app will support. Both Google and Apple provide statistics on the relative number of devices running each version of their operating systems. This data can be quite helpful in choosing which OS versions to support.
One of my clients regularly updates the minimum supported version of the operating system as new ones are released. This helps keep the code simpler and easier to maintain and test because it isn’t cluttered with options for older and outdated versions of the operating system.
Regardless of your OS version choice, it is best to keep up with and test updates to the operating system and tools so that your app takes advantage of the latest and greatest features and security. And the fact is, most of your users will be upgrading to the latest version whether you want them to or not.
Multiple Target Devices
So, we’ve narrowed down the versions of the operating system to support, but that still leaves multiple target devices. The range is significantly smaller with iOS devices while the Android market is fragmented across a very large number of manufacturers with a few leaders. To complete development and testing efficiently and release your app before it becomes outdated, it is very important to limit the supported mobile devices. Google provides statistics on screen sizes and densities at the link mentioned above. Data on specific devices in use is available at other websites.
Even with limiting the supported devices, the app needs to be responsively designed so that it will render targets not explicitly chosen to be supported. This will provide the best user experience for users of phones not explicitly tested.
Summing It All Up
As described above, development of mobile medical apps needs to overcome challenges that traditional medical applications do not typically have due to the nature of mobile devices. By limiting the platforms and ensuring protection of personal information, the development process can proceed in a timely fashion while meeting all of the regulatory requirements.
Comments are closed.