Over the past two decades, perhaps the most significant change to the medical device industry has been the incorporation of software into a burgeoning number of medical devices. While this development trend has resulted in increased functionality and sophistication, including better control of devices, more power to end-users, and phenomenal gains in diagnostic and usage data gathering and dissemination, it has also raised a host of issues and questions.
While not simple to understand how software safety, functionality, and control works in the sphere of medical devices, the FDA and ISO have provided significant guidance, which can become the basis of a development process that meets regulatory and user requirements. By establishing requirements, developing a process that meets them, following that process carefully, and steadily producing artifacts which document each step along the way, medical device manufacturers can ensure that the software component(s) of their devices will perform to expectations without causing costly delays or roadblocks to development, approval, release, or postmarket.
In this series, Sat Ketkar will provide a high-level overview of the controls needed to develop medical device software that meets accepted standards and merits regulatory approval.
Is Software a Device?
The FDA’s definition of a medical device is clear. Since 2010, the FDA has been equally clear that software than in any way interacts with a medical device or works alone in the attempt to diagnose, cure, mitigate, treat, or prevent a disease, is itself a device.
Once software was classified as a device, it, in turn, became necessary for software to comply with 21 CFR Part 820 (even the sections that do not specifically mention software). Any medical device that contains or is composed of software is not compliant with regulatory requirements unless the software has undergone risk management, configuration management, requirements management, design controls, verification/validation, and other requirements of Part 820.
Each of these components of software development must occur within a quality management system and include the required documentation to prove compliance.
Who is Responsible?
When the scope of compliance requirements surrounding medical device software is understood, it becomes evident that software development has a high potential for risk / benefit impact on patients and end-users. No wonder, then, that software development controls can make or break device approval! Devices that are otherwise Part 820 compliant and have useful clinical data on safety and efficacy will still be denied market approval if the software development process and documentation are not compliant.
Medical device companies often outsource software development for strategic or financial reasons. However, it is still the device manufacturer of record that is responsible for showing that the software in their device meets regulatory requirements. The device manufacturer that outsources software development, therefore, has two choices: either lead the software consultant through a development process that will ensure compliance or hire a consultant that is knowledgeable of requirements and has developed its own certified process by which to ensure compliance.
In the medical device industry, it is simply not enough to hire competent programmers for device software development. Skilled programmers are necessary, but they must also work within a disciplined framework of a software development process tailored to the FDA and other regulations. In our next installment of this series, we will cover in more detail what that software development process really looks like. If you’d rather not wait, click here to download our free white paper!
