---
title: "Software and AI Medical Device Compliance | Qualio"
canonical: "https://www.qualio.com/solutions/software-and-ai"
updatedDate: "2026-11-03T14:07:40.000Z"
description: "Change records categorised before each release ships, evals and tests traced from Jira, GitHub and Azure DevOps, and a technical documentation snapshot for every version. IEC 62304, ISO 14971, EU MDR and ISO 42001."
---

# Software and AI Medical Device Compliance | Qualio

Change records categorised before each release ships, evals and tests traced from Jira, GitHub and Azure DevOps, and a technical documentation snapshot for every version. IEC 62304, ISO 14971, EU MDR and ISO 42001.

## Update your AI medical device without waiting on the paperwork

For your first certification, every update and each new device, Qualio keeps the change record, the evidence and the technical file.

## The work is done. The evidence is somewhere else.

Requirements sit in Jira, evals run in CI, and the model sits with its provider. When the notified body asks, someone pulls it together by hand.

### The first submission, rebuilt from tickets

The design history is spread across tickets and pull requests, so turning it into a technical file is a project of its own.

### The evals nobody can show

The eval suite runs on every build. The results never reach the design history, so the auditor sees a test plan with no evidence behind it.

### The update with no decision on file

A release went out without a change record because it did not need reporting. Later, nobody can say what changed or why.

### The second device starts from scratch

A new product or market means copying documents, when it could start from the version already approved.

## Each release gets its change record, its trace and its file

Raise a change as a change request in Qualio, or in your tracker and Qualio imports it. Change types follow your procedure, so each change is categorised before it ships: reportable with prior approval, reportable without, or non-reportable.

A predetermined change control plan is a controlled document, and each change under it is a change request. Every change keeps its record, so the ones the notified body samples are already on file.

To a quality system ready for 510(k).

## Your engineers stay in Jira, GitHub and Azure DevOps

Qualio reads requirements, tests and their links as they are, every hour, and writes nothing back. The trace matrix rebuilds on every change.

- A requirement with no test is marked before the design review
- Eval results arrive as test results from TestRail, Xray, Zephyr Scale, the API or MCP, each traced to its requirement and risk
- Ask about a requirement or its trace from Claude or Cursor, over MCP

## Each version keeps its own file

Apply the EU MDR or 510(k) framework to a product version, and each section lists the document that answers it at its approved version. Take a read-only snapshot when you submit, downloaded as one zip.

- Version 2.0 starts from the 1.0 baseline and marks what changed
- Approve the design review and the trace matrix, risk file and test plans generate
- Register in a second market from the same documents, through the controls its framework shares

## When the model changes, the record changes with it

The model is a design output and a line on the bill of materials, and its provider is a supplier, ranked by risk. When the provider retires a version or you move to a new one, one change request links all three, with the risks and tests that trace to the model.

- Re-run the tests linked to the model before the switch goes live
- The provider's notices and your assessment stay on the supplier record
- ISO 42001 is in the framework library, assessed clause by clause like ISO 13485

## What software and AI device companies say

## More for software and AI teams

## Less time on the file. More time on the product.

Bring your last release. We will read it from your tracker, raise its change record and show the file for that version in Qualio.