The following questions come from the Software as a Medical Device Regulations and Compliant Development Environments webinar.
Quick Summary
- Not all health and fitness software is regulated — the 21st Century Cures Act exempts general wellness apps, while software that diagnoses, treats, or analyzes clinical data is a medical device.
- Automated design control is tool- and cloud-agnostic: it configures your CI/CD pipeline so requirements, design, testing, and approval happen continuously rather than in linear, siloed phases.
- GAMP 5, the FDA's Case for Quality, and Computer Software Assurance (CSA) all push teams toward critical, risk-based thinking about product quality and patient safety — not less testing.
- Continuous compliance testing running daily in the background produces the human-readable evidence that Quality teams and auditors need.
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.
The line is intent and function, not deployment. Where your software runs matters far less than what it does. The same cloud application can fall outside FDA scope or squarely inside it depending on whether it merely moves data or interprets it. Establishing clear data lineage and intended use early makes that determination defensible.
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.
Instead of treating requirements, design, testing, and approval as separate hand-offs, an automated design control process reviews, tests, and approves along the way — turning a linear, waterfall process into an agile one.
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.
From CSV to CSA: what changes
- Think critically first. Apply effort where patient safety and product quality risk is highest, instead of documenting every test at the same depth.
- Partner IT and Quality. Procedural change is a joint effort — both functions decide what risk-based testing means for your products.
- Assess your whole landscape. Readiness is about your systems, processes, and tooling together, not a single SOP edit.
- Keep the rigor. Computer Software Assurance (CSA) doesn't remove testing or requirements — it focuses them.
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. This is the same philosophy behind USDM Cloud Assurance — keeping validated systems in a continuously compliant state rather than re-validating in periodic, disruptive cycles. For teams formalizing this discipline, a structured approach to validation lifecycle management ties requirements, testing, and evidence together across the system's life.
Because SaMD products and their development pipelines handle regulated data and electronic records, the same environments must also satisfy 21 CFR Part 11 expectations for records and signatures — another reason continuous, automated evidence collection pays off.
FAQ: SaMD Regulations and Compliant Development Environments
Is every health or fitness app regulated by the FDA as a medical device?
No. Under the 21st Century Cures Act, software for general patient education or for maintaining and encouraging a healthy lifestyle — unrelated to the diagnosis, cure, mitigation, prevention, or treatment of a disease — is not a medical device. If an app helps reduce the risk or impact of certain chronic diseases or conditions, it is considered a medical device, currently under the FDA's enforcement discretion.
When does cloud software that manages IVD instrument data become regulated?
If the software solely transfers, stores, converts formats, or displays clinical laboratory test or device data, it is a non-device Medical Device Data System (non-device-MDDS) and is not a medical device. Once it analyzes or interprets that data, it becomes an MDDS subject to FDA regulatory requirements.
How is Computer Software Assurance (CSA) different from traditional CSV?
CSA, GAMP 5, and the FDA's Case for Quality all ask teams to think critically about product quality and patient safety and to apply risk-based testing where it matters most. It is not about giving up testing or requirements — it is about a partnership between IT and Quality to focus rigor where risk is highest.
Is an automated design control process tied to a specific tool or cloud?
No. It is tool- and cloud-agnostic. It configures your CI/CD pipeline so requirements, design, development, testing, and approval happen continuously rather than as separate linear phases, making a waterfall process more agile.
How does continuous compliance testing support audits?
Continuous compliance testing runs daily in the background and produces human-readable reports that Quality teams and auditors can review, keeping requirements current and closing the loop on changes as systems evolve.
Bring SaMD Compliance Into Your Development Pipeline
Whether you are determining whether your software is regulated, modernizing CSV into a risk-based CSA approach, or building continuous compliance into your CI/CD pipeline, USDM can help you do it without slowing innovation. Contact us to talk through your SaMD and compliant development environment goals.
Additional Resources
Solutions for Medical Device Manufacturers
Lessons from the USDM Cloud Assurance Box GxP ATT
An Open Letter to Medical Device Regulators