Q&A: SaMD Regulations and Compliant Development Environments

The following questions come from the Software as a Medical Device Regulations and Compliant Development Environments webinar.

Are all fitness devices exempt from U.S. Food and Drug Administration (FDA) requirements?

No. The 21st Century Cures Act (Cures Act) modified the Federal Food, Drug, and Cosmetic Act (FD&C Act) such that software or mobile apps for general patient education or that are used “for maintaining or encouraging a healthy lifestyle and is unrelated to the diagnosis, cure, mitigation, prevention, or treatment of a disease or condition” are not considered medical devices. However, if the software or app relates the role of healthy lifestyle by helping to reduce the risk or impact of certain chronic diseases or conditions, then the product is considered a medical device. At this time, these products are under the FDA’s enforcement discretion.

We make a cloud-based software solution that manages data from third-party In Vitro Diagnostic (IVD) instruments. Is our software regulated?

It depends on what you mean by “manages.” If it is solely for “transferring, storing, converting formats, or displaying clinical laboratory test or other device data,” then it is non-device Medical Device Data System (non-device-MDDS) and is not considered a medical device. If the software also analyzes or interprets data, then it is MDDS and is subject to FDA regulatory requirements.

Is the automated design control process software specific? Is it cloud specific?

It’s not. This type of automated design control process can be put on whatever cloud you’re using, whatever DevOps tools you’re using. It configures your CICD pipeline to match the processes so you move through that process quicker. Instead of gathering the requirements, gathering the design and development activity, gathering testing as a separate activity as we move through it, we review, test, and approve along the way. It makes a traditional linear process or water flow process more agile.

What do we do in regard to the conventional Good Automated Manufacturing Practice (GAMP) 5 and CSV approach versus what the FDA’s Case for Quality program has been projecting with regard to Computer Software Assurance?

GAMP5, Case for Quality, and CSA want us to think critically about product quality and patient safety. When moving to this methodology, there is a partnership between IT and Quality to determine procedural changes that are needed within your company to ensure software validation and Software as a Medical Device quality. You must determine what risk-based testing looks like for you. Your readiness involves looking at your whole landscape and putting those changes in place.

We’re not giving up testing and requirements but ensuring that we care about product quality and patient safety.

What are the tools USDM uses for testing automation?

Azure DevOps can do testing within the application. SpiraTest and Rapise are two tools that can latch onto almost all cloud infrastructures so they give us the ability to keep requirements up to date. They help us close the loop on changes, do automated testing of requirements, and make sure it’s in human-readable format because auditors must also be able to read the results.

We do continuous compliance testing that runs in the background daily and provides reports that the Quality team and auditors want to look at.

Additional Resources

Solutions for Medical Device Manufacturers
Lessons from the USDM Cloud Assurance Box GxP ATT
An Open Letter to Medical Device Regulators