Why Medtech needs QA for compliance

When a software defect can harm a patient, compliance turns into the mechanism that protects them. It builds a verifiable chain from risk to requirement to test, so medtech teams can show auditors clear proof of control and give clinicians confidence at the point of care.

Medical device software operates in a completely different reality than consumer applications. A coding error in a streaming app might cause frustration, but a similar error in a clinical device, like an insulin pump, could directly harm patients. This fundamental difference in risk is precisely why regulatory bodies approach software validation with such scrutiny.

The concern is also growing. FDA officials reported that Class I medical device recalls increased by 232% between 2020 and 2025. In 2026 alone, the FDA’s public list of serious medical device recalls and early alerts includes issues involving insulin pumps, infusion pump software, ventilators, pacemakers, heart pumps, blood glucose monitors, anaesthesia equipment, dialysis bloodline sets, and paediatric care beds.

Medtech QA also has to match updated US quality rules. The FDA’s Quality Management System Regulation, effective February 2, 2026, brings US medical device rules closer to the ISO 13485:2016 quality standard. For QA teams, this means testing needs to do more than confirm that the software works. It also has to create clear proof that risks were managed, design choices were checked, suppliers were controlled, issues were fixed, and post-release feedback was acted on.

For auditors, testing is the formal process of generating traceable proof that every risk is controlled. Failing to provide this specific proof, the link between a risk and its test, is seen as a fundamental safety failure, which translates directly into lost revenue and competitive disadvantage.

The following testing types represent where this proof and rigorous testing converge to create the compliance foundation that regulators evaluate.

1. Risk-based & functional testing

Risk management per ISO 14971 underpins the entire product lifecycle, with testing providing the evidence that risk controls are effective. This standard is important because it provides the framework for transforming abstract clinical risks (like an incorrect dosage) into testable control mechanisms (like input validation). The QA team's role is to execute specific tests that prove these controls work:

• Risk-based functional tests: Verifying that the software behaves as expected under both normal and invalid conditions, directly testing the risk control.
• Boundary value analysis: A more rigorous form of testing that focuses on the edges of acceptable inputs (e.g., minimum and maximum values) where errors are common.
• Fault injection: Deliberately forcing error conditions (e.g., simulating a sensor failure) to verify the software fails safely, such as by triggering an alert.
• The traceability mandate: QA is responsible for creating and maintaining the Requirements Traceability Matrix (RTM). This is the auditable backbone of the project, linking every requirement to its risk control and its test. A design control deficiency is often a finding that this matrix is broken or incomplete.

2. Software lifecycle & code-level testing

This category of testing is dictated by software lifecycle standards, such as IEC 62304, which require a process that ensures software quality and safety. This standard works in tandem with the system-level risks from ISO 14971. Higher-risk software (like Class C, which could cause serious injury) requires more thorough testing. The QA team's role is to ensure these specific testing types are performed:

• Static code analysis: Using automated tools to scan source code for vulnerabilities, bugs, and deviations from coding standards before the software is even run.
• Formal code reviews: A documented, manual process where peers review code to ensure it is correct, maintainable, and adheres to design and safety requirements.
• SOUP validation: Formally testing Software of Unknown Provenance (SOUP), any third-party or open-source library. The manufacturer inherits 100% of the risk for this code, and QA must prove it meets safety and performance requirements.

3. Usability & human factors testing

Usability testing helps ensure that a device's software interface is clear and safe to use. This testing, guided by standards like IEC 62366, is an essential risk-control activity to prevent user errors. QA must ensure this testing happens at two key stages:

• Formative tests: Exploratory tests run during development, where users think aloud while performing tasks. This helps the team find and fix design flaws early.
• Summative tests: This is the final, formal pass/fail validation of the finished product. While the IEC 62366 standard defines the process, regulatory bodies like the US FDA strongly recommend a minimum of 15 representative users per user group (e.g., 15 patients, 15 clinicians) to provide strong validation data.

4. Cybersecurity & security testing

New laws in both the US (Section 524B) and EU (MDR GSPR) make cybersecurity testing a requirement. A failure here can lead to an automatic refuse to accept status. These laws require proof that the device is secure. QA must oversee a layered testing approach to build this proof:

• SAST (Static Application Security Testing): Automatically scanning the code for security flaws before it's run.
• DAST (Dynamic Application Security Testing): Testing the running software from the outside to find weaknesses.
• Penetration testing: Using security experts to try and hack the software to find flaws a real-world attacker would use.

5. Performance & load testing

Performance failures, like a lagging UI during an emergency or system freezes, are clinical risks. Testing must validate that the software performs reliably under real-world conditions, as required by the EU's General Safety and Performance Requirements (GSPR). Testing types include:

• Load testing: Simulating concurrent usage, such as many devices reporting to a central server at once.
• Stress testing: Pushing the system beyond its expected capacity to identify failure points and, critically, to verify it recovers gracefully without data corruption.
• Soak testing: Running the system under a normal load for an extended period (e.g., 48-72 hours) to find subtle, long-term issues like memory leaks or resource depletion.

6. AI/ML model validation

Artificial intelligence introduces a new validation challenge: proving both the code and the data are safe. This requires a new set of testing protocols to address unique risks. QA's validation role includes:

• Data validation: Examining the training and test datasets for completeness, accuracy, and potential bias that could affect clinical outcomes across different patient populations.
• Model robustness testing: Challenging the AI with adversarial or out-of-distribution data (scenarios it was not trained on) to verify its performance boundaries and ensure it fails safely.
• Understanding regulatory paths: The validation strategy must account for divergent global frameworks. The FDA's PCCP framework provides an adaptive path, allowing QA to help document a plan to get the process of future changes pre-approved. Concurrently, the EU AI Act provides a prescriptive path, requiring QA to comply with a legal layer that classifies most AI devices as high-risk by default.

7. Interoperability & data exchange testing

As devices connect to hospital Electronic Health Records (EHRs), their ability to safely exchange data is a compliance area mandated by laws like the 21st Century Cures Act. QA must validate that data is sent correctly and securely using established healthcare standards.

• Standards validation: Testing compliance with data standards like HL7 v2 (the legacy standard) and FHIR (the modern API-based standard).
• Profile conformance: Proving the device can function in a real hospital ecosystem. This involves testing the device against specific clinical profiles to ensure it can correctly and safely communicate with other systems.

8. Continuing compliance: post-market monitoring

This area is about ensuring safety and compliance after a product is launched. This closed-loop process is an important part of keeping tabs on real-world performance. Regulators mandate that all manufacturers have systems in place for this, which generally involves two parts:

• Medical device reporting: Fulfilling the legal duty to report serious incidents to regulatory bodies within their strictly enforced timelines.
• Proactive surveillance: Systematically gathering data from the field to analyze trends and identify potential issues before they become serious incidents.

Integrating compliance into the modern SDLC

Treating these testing areas as a final checklist is a common pitfall. This approach creates a compliance bottleneck, where all validation is saved for the end, delaying release and isolating safety from development.

A modern, more effective approach is to weave these activities directly into the development process, such as Agile and DevOps. This integration creates a digital thread, an auditable, real-time link between a requirement, its risk, the code, and its test. Instead of a linear V-model of development, compliance becomes an iterative part of every sprint, following a feature from its conception to its post-release monitoring.

• In planning: The risk analysis and usability requirements are not just QA documents; they are the source of truth that defines the User Stories for the development team.
• In development: A feature isn't done when the code is written. The "Definition of Done" for a sprint becomes an auditable checkpoint that now includes: code written, unit tests passed, risk controls verified, and the traceability matrix updated.
• In CI/CD: The automated pipeline becomes the first line of compliance. It automatically runs code scanning (SAST) and dependency checking (SCA), preventing non-compliant code from ever being merged.
• In validation: Formal testing (performance, interoperability, and the final summative usability test) becomes the last step to validate the entire integrated system before release.
• After release: The post-market monitoring loop is just another form of production observability. Real-world data from logs and user reports feeds directly back into the product backlog to drive the next patch or version.

Conclusion: From validation to assurance

This integrated approach transforms compliance from a pre-submission bottleneck into a continuous process. It marks a fundamental shift in regulatory thinking, moving from old models of Computer System Validation (CSV), which were documentation-heavy and often treated all features as equal, to a modern philosophy of Computer Software Assurance (CSA).

This new, risk-based approach encourages critical thinking and focuses rigorous testing on high-risk functions while reducing the burden for low-risk ones. By building quality into the development cycle, teams can build safer products, experience fewer post-market issues, and achieve faster, more predictable regulatory approval. It shifts the mindset from doing this for the auditors to doing this to build a better, safer product.