Imagine this situation: a customer comes in and says “I’m building a wearable that will help cure Alzheimer’s disease. I need you to write software that will analyze the data from my device. Are you in?” Sounds familiar, right? Like many similar questions you’ve heard before. Of course, you like this idea, the project is interesting, you’ve developed plenty of mobile apps before… why not say “yes”?
Just so you know: this article is not intended to scare you away from writing mHealth software. Its goal is to show you some specific aspects of the mHealth software development process. Otherwise you might be pretty astonished when the FDA guys knock your door one day and start checking your source code.
I assume those who didn’t know what the FDA was have already googled it, so we can skip the introductory part. Your mHealth app might need to be HIPAA compliant, but it’s rather rare, so we won’t elaborate on HIPAA compliance in this particular article. Instead, we’ll concentrate on FDA compliance, because it greatly affects the whole development process.
First of all, you need to make sure you know what kind of application you’re going to develop. If your app belongs to one of following groups:
- Software that is actually a part of the medical device itself
- Software that is an accessory to a medical device
- Software that in itself is a medical device
then you’re in the right place. The definition of a mobile medical application is presented here.
So, how can FDA regulations affect your mHealth app development process? Here’s a list of issues to consider, with references to our latest experiences in developing an application for our US-based biotech customer.
Rigid quality assurance process
When developing the system, the Espeo team had to put much more effort into quality assurance than usual. All acceptance criteria and test cases had to be specified and written down. We couldn’t just agree verbally with our customer, because the conclusions had to be recorded.
Software verification
Espeo could employ static source code analysis in order to detect critical bugs and security vulnerabilities. We also took software metrics analysis and trending into account. Thanks to those tools we were provided with an independent, automated review of source code. Afterwards, all reported bugs could be tracked for each release. We could also prioritize all the bugs. Needless to say, we used code review tools, so all commits were checked by peers before they were merged to the newly released version.
Controlled, but still agile
One of the first questions we asked ourselves was whether FDA compliance allows for agile development. Some were saying that FDA regulations don’t go together well with agile rules, which involve less documentation, an emphasis on productivity and the promotion of quick development, which allows software to be a bit buggy in its early phases. Our testers had to prepare test cases for each story, in order to keep track of the requirements and how they were verified. Another important action was to perform a regression test after each release, so that older functionalities were not broken by new ones.
Documentation
We had to prepare an informative documentation of the system. This didn’t only include comments in the source code, but also several technical documents, system architecture, a plan and description of tests.
To summarize, a development of an FDA-compliant application means more work for the development team, higher test coverage of the code and, in general, a more strictly controlled process. In return, your application is really a high quality product from its first release. And you have a lot of documentation to show to the FDA when they knock on your door one day.
