Device makers lose review time when test evidence does not trace back to requirements and risk controls. Agnotic Technologies plans and runs verification and validation for medical device software and SaMD, and produces the records IEC 62304 and an FDA premarket submission expect.
Trusted by global innovators
Verification and validation
Verification and validation for medical device software is the evidence that the software was built right and that it is the right software. Verification checks each design output against its requirements; validation checks the finished software against user needs and intended uses. Agnotic Technologies plans both activities and produces the test records a device maker submits.
This page is about the evidence. Choosing the FDA pathway and classifying the device sit on our FDA SaMD compliance page, and premarket cybersecurity work sits on our medtech engineering page.
How much evidence you need depends on two classifications that are easy to mix up: the IEC 62304 software safety class (A, B or C) and the FDA documentation level (Basic or Enhanced). We settle both at the start, because together they decide which tests are written down and how.
Decision table
Our working summary of IEC 62304:2006 with Amendment 1:2015. Your quality team confirms the class and the final plan against the standard text.
| Activity and record | Class A | Class B | Class C |
|---|---|---|---|
| Development plan and software requirements | Required | Required | Required |
| Architecture design, with SOUP requirements and segregation for risk control | Not required | Required | Required |
| Detailed design of each software unit and its interfaces | Not required | Units identified; detailed design not required | Required and verified |
| Unit verification against acceptance criteria | Not required; units are implemented | Required | Required, with added criteria such as fault handling, data flow and boundary conditions |
| Integration and integration testing | Not required | Required | Required |
| Software system testing | Required | Required | Required |
| SOUP records | Title, manufacturer and version | Plus functional and performance requirements and a review of published anomaly lists | Same as class B |
Class C needs the most records, but class A still needs requirements, system testing and a controlled release. Low risk never means no evidence.
FDA documentation level
FDA's device software guidance sets two documentation levels. The level follows the worst credible harm a software failure could cause before risk controls are applied, not the device class alone.
Example: Software where a failure could not lead to a hazardous situation with a probable risk of death or serious injury.
Approach: A summary of unit, integration and system testing, the system level test protocol and report, the tested version history and the list of unresolved anomalies with their impact.
Example: Software where a failure could present a hazardous situation with a probable risk of death or serious injury.
Approach: Everything at the Basic level, plus unit and integration test protocols and reports, and a software design specification that traces to the requirements.
Traceability
Sample rows for an illustrative dose calculator feature. Every requirement links to the hazard it controls, the test that verifies it and the recorded result.
| Requirement | Hazard and risk control | Verification | Evidence |
|---|---|---|---|
| SRS-112: reject a dose entry above the configured maximum | HAZ-07 overdose from a typing error; control RC-07 input limit check | Unit tests at, below and above the limit; system test ST-31 | Pass in build 2.4.0, linked to the CI run and the signed test report |
| SRS-118: show the unit of measure beside every dose value | HAZ-09 unit confusion; control RC-09 labelled display | Usability validation task with intended users; system test ST-36 | Task results and observed use errors in the usability report |
| SRS-140: keep the last confirmed dose if the sync service is down | HAZ-12 stale data shown as current; control RC-12 staleness banner | Integration test with the sync service stopped | Pass, with the related anomaly closed in build 2.4.1 |
We generate this matrix from the links stored on each requirement and test case, so it is never retyped by hand before a submission.
Failure points
Problems we see when device teams prepare a submission or an audit, and the control we put in place.
Challenge
Tests pass, but nobody can show which requirement or risk control each test covers.
Agnotic approach
Every test case carries the IDs of its requirement and risk control, and the trace matrix is generated from those links.
Challenge
The software safety class was assumed, not argued, and changes late.
Agnotic approach
We write the class rationale from the hazard analysis in the first sprint and revisit it when the architecture changes.
Challenge
Third-party libraries ship in the build but are missing from the SOUP list.
Agnotic approach
The SOUP list is produced from the dependency manifest in CI, so a new library cannot ship without a record.
Challenge
Automated tests run in CI, but the evidence lives only in pipeline logs that expire.
Agnotic approach
Results are exported per build, reviewed, signed off and stored with the version they tested.
Challenge
A small fix ships without regression evidence.
Agnotic approach
Change impact analysis names the affected requirements, and their regression tests run before release.
Challenge
Validation is a demo for the product team, not a study with users.
Agnotic approach
Usability validation runs with representative intended users in realistic use environments, following IEC 62366-1 and FDA human factors guidance.
Verification and validation services that fit your quality system instead of running beside it.
Scope, test levels, environments, entry and exit criteria and sign-off roles, mapped to your QMS procedures.
Requirement to risk control to test case to result, generated from your tools and kept current on every build.
Automated tests written to the acceptance criteria your safety class needs, run on every merge.
Protocols with expected results, executed with observed results and pass or fail, ready for the submission.
Version, purpose, known anomaly review and the requirements each item must meet.
Use-related risk inputs, task scripts and summative study support with intended users.
Change impact analysis, regression runs, and an updated version history and anomaly list for each release.
Build-tagged test results, coverage and static analysis output exported as controlled records.
Who it is for
Device and digital health teams whose software needs evidence a reviewer can follow.
Teams preparing a first premarket submission who need the evidence built alongside the product.
Firmware and companion app teams whose software is part of a physical device.
Changes that need change impact analysis and regression evidence before release.
Trace gaps and SOUP records closed before an inspection or a notified body audit.
Products crossing from wellness into device functions, which need a V&V process for the first time.
Standards
The standards and rules behind the tables above.
Health Insurance Portability and Accountability Act
Protect PHI with privacy-first architecture, encrypted storage and transmission, strict access controls, and traceable audit logs.
General Data Protection Regulation
Implement lawful consent flows, data minimization, retention controls, and secure processing for sensitive health data.
Fast Healthcare Interoperability Resources
Enable standardized health data exchange across apps, care teams, and systems through standards-based FHIR APIs.
Health Level Seven International
Support enterprise-grade interoperability with HL7-based integrations for records, events, and clinical messaging workflows.
Health Information Trust Alliance
Align security programs to healthcare-specific control and risk management practices trusted by providers and ecosystem partners.
Health Information Technology for Economic and Clinical Health Act
Design with breach notification readiness, digital record safeguards, and operational controls that support regulated care programs.
FDA Software as a Medical Device
Plan software quality, traceability, and documentation pathways for products that may require SaMD review and submission.
Medical Device Regulation (European Union)
Prepare EU market-ready processes for risk classification, evidence tracking, and lifecycle governance under MDR expectations.
Substance Abuse and Mental Health Services Administration
Apply confidentiality controls and consent-aware sharing models for behavioral and mental health data experiences.
Rules and guidance behind this page, each linked to its primary source.
FDA recommends Enhanced Documentation in a premarket submission when a failure or flaw of any device software function could present a hazardous situation with a probable risk of death or serious injury, judged before risk control measures are applied.
Source: FDA, Content of Premarket Submissions for Device Software Functions (June 2023)At the Basic Documentation level FDA asks for a summary of unit, integration and system testing plus the system level test protocol and report; the Enhanced level adds unit and integration test protocols and reports with expected results, observed results and pass or fail determinations.
Source: FDA, Content of Premarket Submissions for Device Software Functions, Table 1FDA describes software verification as objective evidence that the design outputs of a life cycle phase meet the requirements specified for that phase, and software validation as confirmation that software specifications conform to user needs and intended uses.
Source: FDA, General Principles of Software ValidationUnder the Quality Management System Regulation, manufacturers of class II and class III devices, and of class I devices automated with computer software, must comply with the design and development requirements in clause 7.3 of ISO 13485.
Source: 21 CFR 820.10(c) (eCFR)IEC 62304 sets life cycle requirements for medical device software, whether the software is itself a medical device or part of one, and does not cover validation and final release of the medical device.
Source: IEC 62304:2006 (IEC webstore)Three stages, each with a clear output for your quality team.
We review your requirements, hazard analysis, existing tests and records, and agree the safety class and documentation level.
ScopeWe write the V&V plan, add trace links, build the automated suites and draft the protocols.
BuildWe run the protocols on the release candidate and hand over reports, the trace matrix and the anomaly list.
EvidenceScope and cost
We do not publish prices. These are the things that change the size of the work, priced after the scoping call.
Class C software at the Enhanced level needs unit and integration protocols as well as system tests.
Whether requirements, hazard analysis and tests already exist and link to each other, or need to be built.
Test rigs, device simulators and the connected systems the software talks to.
How many user groups and use environments need a summative study.
How often you release, which sets how much regression evidence is produced.
The requirements, test management and ALM tools your QMS already uses.
