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.

THE STAKES

The notified body samples changes you never had to report, and each one it picks needs a record

Built around the release

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.

The Results

90 days

To a quality system ready for 510(k).

Simbiosys

Traceability

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

Qualio requirement US-17 Patient Scan Annotation Limits linked to Jira, with open traceability issues and its user need

Technical documentation

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

Qualio 510(k) submission for the CardioSync App, showing requirement progress, gaps and the controls of each submission section

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.