Healthcare Software

Developing Software in an FDA Regulated Environment

A lot of focus is often given to the development lifecycle followed and how it can help or harm the process of getting and retaining FDA premarket approval. Some believe that since the FDA is more familiar with a traditional waterfall process it is advantageous to use the same. The logical argument given is that it would simplify the audit process because there would be no need to explain your alternate process. In reality, the lifecycle you choose to follow is entirely up to you since the law, like a good requirement, will never over constrain itself against evolutionary improvement.

The key to passing an FDA review or audit as far as the software of a device is concerned is to have a sound development process in place and ensure that it is followed with the knowledge that it will be scrutinized when applying for FDA approval. The need to back up your process with evidence is fulfilled by good management empowered with good tools. For example, using a requirements management tool will help to track relationships between requirements as they get added, removed or modified. Such a tool will also provide links between requirements and design and test plan documentation. These tools have extended their use into agile development processes as is the case with Inflectra’s SpiraTeam product. More general solutions come in the form of the popular Telelogic DOORS. Using these tools allow you to build traceable documents and help you to conform to FDA standards.

Keep in mind that the main focus of the FDA is to ensure that a medical device satisfies user needs and intended uses. You have to have the evidence in the form of requirements and design documentation, quality and test reports to show that the software will not cause a malfunction in the environment in which it operates. Providing these and showing that your development process is mature is greatly simplified when you have the right software tools to support it. Ideally, this should be no different from developing software outside of a regulated environment with only the additional step of being subject to governmental approval.