Medical Device Software Testing

What is medical device software testing?

Medical device software testing is the planned verification and validation of software that has a medical purpose, either as Software as a Medical Device or inside a hardware device. It confirms every software requirement, proves each risk control works, checks cybersecurity and produces traceable records that support the manufacturer's quality system and FDA submission.

Is your software a device at all?

• Software as a Medical Device: Software intended for a medical purpose that performs it without being part of a hardware device. FDA uses the IMDRF definition.
• Software in a device: Firmware and companion apps that drive or are part of a hardware device, such as many BLE sensors and bedside monitors.
• Not a device: Administrative, scheduling or EHR functions with no device purpose, and some clinical decision support that meets the criteria in FDA's January 2026 CDS guidance. These still need security and access testing if they hold ePHI.

Device status is a separate question from device class. Settle intended use first, then the FDA class and pathway, then the IEC 62304 software safety class.

Which FDA rules and standards set the bar?

The manufacturer carries the regulatory duty, and its quality system decides how testing is planned and recorded. These are the references a device test plan should cite.

• Quality Management System Regulation: Since 2 February 2026, 21 CFR Part 820 incorporates ISO 13485:2016 by reference. The QMSR is the device maker's quality system duty, including design verification and validation.
• IEC 62304: A voluntary, FDA-recognized standard for medical device software life cycle processes. It expects verification of all software requirements, with rigor set by the software safety class.
• Premarket software documentation: FDA's June 2023 guidance on the content of premarket submissions for device software functions replaced the 2005 guidance and sets which software records go into a submission.
• Section 524B cyber devices: For a cyber device, the FD&C Act requires a software bill of materials, a plan to monitor and address postmarket vulnerabilities, and processes that give reasonable assurance of cybersecurity.
• Computer Software Assurance: FDA's CSA guidance, current version February 2026, covers software used in production and the quality system, including test tools, and replaced section 6 of the General Principles of Software Validation.

Where a user interface could contribute to harm, FDA's human factors guidance expects use-related risks to be identified and the interface validated with representative users. ISO 14971 risk management usually supplies the hazard list that tests trace to.

How does IEC 62304 safety class change test depth?

IEC 62304 sorts software into Class A, B or C by the worst harm a software failure could contribute to, after external risk controls. The class sets how much unit and integration verification the standard expects.

• Class A: No injury or damage to health is possible. System testing of the software requirements still applies, with lighter design and unit documentation.
• Class B: Non-serious injury is possible. Unit verification and integration testing are added, with defined acceptance criteria for units.
• Class C: Death or serious injury is possible. Unit acceptance criteria go deeper, covering items such as boundary conditions, data and control flow, fault handling and event sequence.

Classification is not a reason to drop requirements from test. Every software requirement needs a verification method, whether or not it links to a hazard. Risk-linked requirements simply need stronger evidence that the control works and stays working after change.

How do the four test layers fit together?

A device test plan works best when it starts from the requirements and hazard analysis rather than a coverage target. Four layers build on each other.

• 1. Unit and integration: Verify units against their acceptance criteria, then test the seams between firmware, the mobile app, the cloud service and any EHR adapter. Replay recorded sensor traces through the parser.
• 2. System and risk controls: Confirm each software requirement against the intended use, and exercise every risk control with abnormal cases such as disconnects, low battery, clock drift, out-of-range values and corrupt packets.
• 3. Cybersecurity: Test authentication, authorization, update signing and rollback, data protection at rest and in transit, and fuzz external interfaces. Confirm the SBOM matches the build that ships.
• 4. Release and regression: Freeze the build identifier, run the regression set after every change including library updates, record anomalies with their risk assessment and keep the exact version that reached users.

Change after release follows the same path. Each fix or update needs an impact analysis that names the requirements and risk controls it touches and the tests that must rerun. For AI-enabled device software, FDA guidance on predetermined change control plans describes how planned model changes, and the testing that will verify them, can be described in the marketing submission ahead of time.

Abnormal cases to write before code

Risk controls only prove themselves under bad conditions. Write these cases from the hazard analysis before implementation starts, so the design has to handle them.

• Input faults: Values outside the sensor range, a stuck reading repeated for minutes, and a negative or zero value where none is possible.
• Timing faults: Readings that arrive late, out of order or twice, and a device clock that jumps after battery replacement.
• Resource faults: Low battery, full local storage and a phone that kills the app in the background.
• User faults: The wrong device paired to a patient, a unit setting changed by mistake and an alert dismissed without being read.

Off-the-shelf components and SOUP

IEC 62304 calls third-party software of unknown provenance SOUP and expects each item to be identified, with its requirements and known anomalies assessed. In practice, every library, BLE stack and operating system version in the SBOM needs a version pin, a reason for use and a check of its published defect list. A library update is a change, so it reruns the regression set.

What a trace matrix row should hold

A trace matrix lets a reviewer move from any requirement or hazard to its evidence in one step. Each row should carry these fields.

• Requirement ID and text: The software requirement as approved, with its version.
• Hazard link: The hazard and risk control it implements, if any, from the risk management file.
• Safety class: The IEC 62304 class of the software item that implements it.
• Verification method: Unit test, integration test, system test, inspection or analysis.
• Test case and result: The test ID, the build it ran on, the date and pass or fail.
• Defect and disposition: Any anomaly raised, its risk evaluation and whether it was fixed or accepted with a reason.
• Release tag: The release in which the requirement and its evidence were approved.

Generate the matrix from tags in the repository and test runner rather than a hand-kept spreadsheet. A generated matrix stays current with each build and shows gaps the moment a requirement loses its test.

How should BLE and cloud links be tested?

Connected devices fail at the radio and network boundary more than in core logic. Test the link as a component with its own failure modes.

• Pairing and bonding: Test first pairing, re-pairing after a phone change, and rejection of an unbonded central.
• Connection loss: Drop the link mid-transfer and confirm the app resumes, does not duplicate readings and shows the user that data is stale.
• Timestamps: Check device clock drift, time zone changes on the phone and readings stored while offline.
• Firmware updates: Interrupt an update at several points and confirm the device recovers to a known good image.
• Cloud sync: Confirm idempotent uploads, ordering of delayed readings and correct handling of an expired token.
• Phone matrix: Run the suite on the operating system versions and handsets your labeling supports, since BLE stacks differ.

Where device test plans fall short

• App-store QA treated as enough: Store review checks policy and stability, not intended use, risk controls or traceability.
• Cybersecurity skipped on small devices: A low-power sensor with a companion app can still meet the cyber device definition.
• Happy-path only: No list of abnormal inputs means risk controls were never exercised.
• Lost release builds: Without the exact shipped version, a field complaint cannot be reproduced or compared with a fix.
• Unvalidated test tools: A harness that decides whether a release passes is quality system software, and CSA guidance expects assurance proportionate to its risk.
• Supplier certificates mistaken for coverage: A software supplier's quality certificate does not replace the manufacturer's own QMSR duty.

How Agnotic can help

Device testing is easiest to defend when the harness is designed with the software. Agnotic Technologies builds BLE device apps and cloud services together with their test harnesses: trace replay, link-failure simulation, update interruption tests and a trace matrix generated from the repository.

Agnotic works inside the manufacturer's quality system, so test records fit its design controls and the manufacturer keeps ownership of the regulatory file.

Sources

• FDA: Quality Management System Regulation (QMSR)
• FDA: Content of Premarket Submissions for Device Software Functions
• FDA: Computer Software Assurance for Production and Quality Management System Software
• FDA: Cybersecurity in medical devices
• FDA: Software as a Medical Device (SaMD)
• IEC 62304: Medical device software life cycle processes
• FDA: Applying Human Factors and Usability Engineering to Medical Devices