Medical Device QMS Software: FDA QMSR and ISO 13485 Guide

What Medical Device QMS Software Should Cover

The best system connects these workflows rather than keeping each one in an isolated folder.

QMSR and ISO 13485 Context

FDA states that the QMSR became effective on February 2, 2026 and incorporates ISO 13485:2016 by reference. FDA also states that it no longer uses QSIT after that date and now uses the updated medical device manufacturer inspection program.

For software evaluation, this means the buyer should ask:

• Does the system support controlled documents and controlled records?
• Can records be retrieved quickly during inspection?
• Can management review, audit, supplier, CAPA, and complaint records be organized?
• Does the system support FDA-specific Part 820 record needs in addition to ISO 13485 alignment?
• Can electronic records and signatures be validated for intended use where Part 11 applies?

QMSR also changes how teams should think about inspection readiness. Under the older Quality System Regulation, certain records had explicit inspection exemptions. FDA's QMSR FAQ states that, after the QMSR effective date, FDA may inspect records that were previously exempt from review under the old QS Regulation, including management review, quality audit, and supplier audit reports. That means QMS software should make sensitive quality-system records controlled, retrievable, and understandable, not hidden in disconnected folders.

The system should also preserve FDA-specific context. ISO 13485 alignment is important, but device companies still need to understand the additional Part 820 requirements that FDA retained or added. A vendor demo that says "ISO 13485 ready" is not enough. The buyer should verify how the platform handles records, complaint files, UDI or labeling context where relevant, corrections and removals, supplier evidence, and inspection copy generation.

Device Quality Records That Should Not Be Scattered

Medical device QMS software is most valuable when it prevents evidence fragmentation. A device team may have design files in one system, risk records in another, supplier files in a spreadsheet, complaints in email, CAPA in a tracker, and submission documents in a publishing workspace. That structure creates risk because the regulatory story depends on relationships among those records.

High-value QMS records include:

The goal is not to put every record in one screen. The goal is to preserve traceability. A complaint that triggers CAPA should link to the CAPA. A CAPA that changes a process should link to change control. A design change that affects labeling should link to regulatory assessment. A supplier issue that affects risk controls should be visible to the team preparing a submission or FDA response.

Design Controls, Risk, and Submission Traceability

Device QMS software should be evaluated against design and risk workflows, not only postmarket workflows. Premarket submissions often depend on controlled design evidence, and postmarket changes often depend on the same evidence after launch.

For design controls, ask whether the system can support:

• Design inputs and outputs
• Design reviews
• Verification and validation planning
• Traceability from requirements to verification evidence
• Design transfer records
• Design changes after release
• Design history file organization
• Links to risk controls and labeling

For risk management, ask whether the system can connect risk controls to verification evidence, complaints, CAPA, and labeling. A risk file that lives outside the quality system may be technically controlled, but it can be operationally weak if postmarket signals never reach it.

This matters for eSTAR because a device submission is not a pile of isolated attachments. FDA reviewers need coherent evidence: device description, indications, risk controls, performance testing, biocompatibility, software, cybersecurity, sterilization, labeling, and other evidence depending on the product. QMS software cannot write the submission, but it should keep the source evidence controlled enough that the submission team can compile and defend it.

Complaint, CAPA, and Postmarket Workflows

Complaint handling is one of the biggest reasons generic workflow software is risky for device companies. A complaint may require investigation, medical device reporting assessment, trend review, correction or removal assessment, supplier follow-up, CAPA, or design change. The QMS software should not treat it as a simple ticket.

A strong complaint workflow should capture:

• Complaint source and intake date
• Device identifier, lot, serial, or product family where applicable
• Event description and alleged failure
• Initial risk or severity assessment
• Investigation decision and rationale
• MDR or vigilance assessment where applicable
• Related nonconformance, supplier issue, or CAPA
• Closure approval and trend category
• Linkage to risk management and design records when needed

CAPA should be reserved for systemic or significant issues, not used as a catch-all task. The software should help show the chain from signal to investigation to root cause to action to effectiveness. If the CAPA changes a product, process, supplier, labeling, or design control, the workflow should trigger change control and regulatory impact assessment.

This is where QMS and regulatory operations meet. A postmarket quality event may affect a future submission, an existing authorization, a labeling commitment, or an FDA response. The earlier the QMS captures regulatory context, the less the submission team has to reconstruct later.

QMS Software and eSTAR Readiness

eSTAR submissions depend on controlled source evidence. A 510(k), De Novo, or PMA package may reference device description, risk analysis, software documentation, verification, validation, biocompatibility, sterilization, labeling, cybersecurity, and clinical or nonclinical evidence.

If those records are scattered or uncontrolled, the submission team has to rebuild traceability during filing.

Medical device QMS software should support:

• Version-controlled source records
• Linkage between risk controls and verification evidence
• Clear design and labeling change history
• Complaint and CAPA trend visibility
• Fast retrieval of records for FDA questions

Assyro connects this upstream evidence to medical device regulatory submission software and eSTAR Validation.

For a 510(k) or De Novo, the team should be able to move from an eSTAR question back to the controlled QMS source. If the submission references a verification test, the approved protocol and report should be retrievable. If the submission references risk mitigation, the risk file and verification evidence should be current. If the submission references labeling, the controlled IFU or label version should match the submission package.

This is also important after clearance or authorization. Device changes may require regulatory assessment. A QMS change control record should identify whether the change affects intended use, indications, design, materials, manufacturing process, supplier, software, cybersecurity, sterilization, packaging, labeling, or risk controls. The outcome may be no submission, a new 510(k), a PMA supplement, a reportable correction or removal, or another market-specific action. QMS software should preserve the decision path.

Buyer Evaluation Checklist

When evaluating medical device QMS software, ask for workflow demonstrations using device scenarios, not generic quality examples.

Also ask about implementation scope. Some device QMS vendors are strong in design controls. Others are stronger in postmarket quality, document control, or supplier quality. The best choice depends on the company's stage, product risk, submission path, and market footprint.

For outsourced device companies, supplier and contract manufacturer access also matters. If design, manufacturing, sterilization, packaging, testing, or complaint investigation work is performed by partners, the QMS has to preserve sponsor oversight without giving every external user inappropriate access. Role design, external collaboration, record ownership, and approval authority should be planned before implementation, not improvised after the first supplier issue.

This planning becomes even more important as the product moves from development to commercial distribution.

Common Buying Mistakes

Another mistake is buying for certification language instead of operating evidence. A company can have polished procedures and still struggle during a submission if design records, risk controls, verification evidence, complaint trends, and labeling history are disconnected. The software should help the team prove what happened and why the decision is defensible.

References

This guide reflects FDA QMSR and Part 820 information current as of May 2026. Confirm applicable requirements, ISO 13485 obligations, and product-specific records before selecting software.