IMSQ ·
Does a SaMD Team Need QMS Software or Specialist Support?
An eQMS organises quality records but adds no expertise or capacity. See when a SaMD team needs specialist support, and book a free IMSQ program review.
Reviewed by Nick Radoux, Director, Codon Partners. Sources checked 29 September 2026.
QMS software gives a medical-device software team a place to control documents, link development records and route approvals. It does not give the team the judgement to assess a requirement, the capacity to finish the work, or the skill to apply its process.
IMSQ, the Institute of MedTech Software Quality, is a platform for medtech software teams. Teams work with vetted industry experts through three kinds of engagement: practical training, expert support and expert delivery.
The short answer: if your gap is record control or traceability, evaluate software; if it is knowledge, judgement or capacity, you need specialist support. Many teams building software as a medical device (SaMD), or software within a medical device, need both. Before replacing your development stack, run the single-change scoping check described below.
Contents
- What is the difference between a medical device QMS and an eQMS?
- Does QMS software close a software-quality gap?
- How does IMSQ help a SaMD team?
- What should a small SaMD team do before buying an eQMS?
- How should you evaluate eQMS and development platforms?
- Does the FDA require ISO 13485 certification?
- Frequently asked questions
- Bring one software-quality problem to an IMSQ program review
What is the difference between a medical device QMS and an eQMS?
A QMS is the organisation's system for managing quality; an eQMS is software that supports it. Buying the software does not establish the system.
A medical device quality management system (QMS) is the organisation's framework of responsibilities, processes, procedures and records for managing quality, with requirements set out in ISO 13485.
An electronic quality management system (eQMS) is software that supports quality processes, such as controlled documents, approvals, training records and corrective and preventive actions (CAPA).
Application lifecycle management (ALM) is software for managing product or software development, connecting requirements, development activities, risks, changes and verification evidence. Some products combine ALM and eQMS capabilities.
Specialist support is expertise or delivery capacity from outside the team: help to design a process, assess a gap, carry out defined work or learn to maintain the approach.
The boundaries between these categories vary by supplier, and some suppliers also sell implementation, training or specialist services alongside their software.
Does QMS software close a software-quality gap?
Not on its own. Software organises the records; people still have to judge whether those records are right.
Consider a traceability matrix in which every requirement has a linked test. The links help, but the team still has to judge whether the requirements are clear, the tests check the intended behaviour and the evidence matches the release under review.
| Problem in your software team | What software helps organise | Where IMSQ support fits |
|---|---|---|
| You have a software development plan template but need to adapt it to IEC 62304, your product and your team | Documents, revisions, review steps and approvals | Expert support to work through the planning decisions and the reasoning behind them |
| Requirements and tests are linked, but the team cannot judge whether the links and evidence are meaningful | Relationships, coverage views and test results | Expert support on requirements and traceability questions |
| The work is understood, but the team lacks the time or expertise to complete it | Tasks, owners, deadlines and progress | Expert delivery of agreed work, with a defined scope and internal review responsibilities |
| Developers and testers have completed training but struggle to apply the process during a change | Training assignments, completion records and workflow steps | Practical training and mentoring tied to the work people perform |
These are scoping examples, not customer case studies. Effective software does not rule out any of these gaps.
How does IMSQ help a SaMD team?
IMSQ is a platform where medtech software teams work with vetted industry experts on the software-quality problems in front of them. The starting point is the task or capability gap your team needs to address, not a tool.
IMSQ's specialist support spans IEC 62304, ISO 14971, ISO 13485, the FDA QMSR, EU MDR and IEC 81001-5-1, and work such as software development planning, requirements and traceability. Current plans are on the plans and pricing page.
Expert support
Bring a challenge, a decision or a document. Work alongside an industry expert to move it forward and understand the reasoning along the way.
Expert delivery
Agree the scope and have an industry expert complete the work. Your team receives the deliverable and a clear explanation of the decisions behind it.
Practical training
IMSQ's practical training is designed by its board of industry experts and tailored to your company. A completion record shows that training took place; applying it to a real change shows whether it was understood.
Worked example: an IEC 62304 software development plan
IEC 62304 sets out life cycle processes for medical device software, including development and maintenance, and development planning is part of that life cycle. A template gives the plan its structure. Your team still decides how activities, responsibilities, traceability, change handling and review points fit its product, software safety classification and development approach.
In expert support, the team builds the plan with the expert, understands the decisions behind it and takes ownership; the deliverable stays with your team. If the gap is time rather than know-how, scope the plan as expert delivery, with the reasoning explained at handover. You retain responsibility for your QMS and regulated decisions.
What should a small SaMD team do before buying an eQMS?
Run a single-change scoping check: take one real change through your current process before replacing any tool. Where it stalls shows whether your gap is in records, knowledge or capacity.
The five steps below use a hypothetical change to how device software handles incomplete input data. Work through them with your own procedures; this is a discussion framework, not a change-control procedure.
1. Describe the change
Record the existing and proposed behaviour, the reason, and who assesses and approves the change. A demonstration should show where this lives; a support proposal should say who helps assess it.
2. Find the affected requirements and risks
Identify the affected user needs, software requirements, interfaces and risk controls. Creating links is easy; judging whether they are correct and complete is the test.
3. Define the evidence needed
Decide how to verify the changed behaviour, including acceptance criteria and regression testing. A tool manages the planned evidence; expertise judges whether it is enough.
4. Carry out and review the work
Follow the ticket, code change, build and test results for one release, including failed tests and a requirement that changes after testing. Check whether the people assigned can complete and review the work within the project's constraints.
5. Close the change
Record the release decision, update affected documents and training, and check that a later reviewer could see what happened and why.
If the team stalls when deciding what to do, that points to expert support. If it understands the work but cannot finish it, scope expert delivery. If the same questions recur across developers and testers, use them to shape practical training.
If you are unsure where to start, two IMSQ tools can help. The free fit check takes about two minutes, with no account needed. The SaMD / SiMD Readiness Diagnostic helps a team screen for likely readiness gaps against relevant standards; it is not a regulatory opinion.
How should you evaluate eQMS and development platforms?
Evaluate them against the work your team must do, not against a feature list. Ask every supplier the same questions and follow one engineering change through each demonstration.
- Who it is for: quality teams, engineering teams or both, and what company size.
- Validation responsibilities: what evidence the supplier provides and what your team must do for its intended use.
- Data export: whether records, links and history leave with you in a usable form.
- Engineering-tool integration: how it connects to your issue tracker, code repository and test tools.
- Licence versus services: what the licence includes and what is sold separately as implementation, migration, training or services.
IMSQ has no commercial relationship with the suppliers below. Each description paraphrases the supplier's own public product information, checked on 29 September 2026; this is not a ranking or a hands-on review.
- Orcanos describes an integrated ALM and quality platform linking requirements, risks and test evidence with quality records. Ask in the demo: How does a change to one requirement show up in its linked risks and tests?
- Matrix One combines Matrix Req, for requirements, risks, tests and traceability, with Matrix Quality, for documents, CAPA, change control, training and audits. Ask in the demo: Which records live in each product, and how do they stay consistent?
- Greenlight Guru offers medical-device quality management with product-development tools that tie requirements, risks and tests to software releases, with Jira and GitHub integrations. Ask in the demo: Can you follow one pull request from its ticket to the release record?
- Tuleap provides medical-device project templates, documented in French, covering requirements, risks, backlogs, test campaigns and traceability. Ask in the demo: Which parts of the template would we need to configure for our own process?
- Qualio offers design-control software covering requirements, risk, and verification and validation, with listed integrations including Jira, Azure DevOps and TestRail. Ask in the demo: Which records stay in our engineering tools and which move into the eQMS?
- MasterControl describes document approval and version control, quality-event workflows and training connected to document changes. Ask in the demo: How does a document change trigger the related training and approvals?
Does the FDA require ISO 13485 certification?
No. The FDA states that it does not intend to require ISO 13485 certification under the QMSR, and a certificate does not replace an FDA inspection.
The FDA's Quality Management System Regulation (QMSR) took effect on 2 February 2026 for manufacturers subject to it. It incorporates ISO 13485:2016 by reference and adds FDA-specific requirements, as the FDA's QMSR overview explains. The FDA's position on certification is in its response to Comment 79 in the QMSR final rule. Requirements in other markets or contracts need separate consideration.
The related standards and regulations have different scopes:
- ISO 13485 sets out quality management system requirements for organisations involved in medical devices.
- ISO 14971 addresses the application of risk management to medical devices.
- IEC 62304 sets out life cycle processes for medical device software, including development and maintenance. Its scope does not cover validation and final release of the whole medical device.
- IEC 81001-5-1 addresses security activities in the health software product life cycle.
- EU MDR, Regulation (EU) 2017/745 governs medical devices placed on the EU market.
A platform can help manage evidence associated with these frameworks. Evaluate its suitability against your product, markets and procedures.
Frequently asked questions
Why use IMSQ if we already have medical device QMS software?
Your eQMS supports records and workflows; IMSQ adds the expertise, capacity and practical learning the software does not. Start with one task your team needs help understanding or completing.
Is an eQMS the same as a QMS?
No. An eQMS is software that supports processes and records. A QMS also needs defined responsibilities, procedures, competent people and a way to review and improve how the system operates.
Can we keep our existing development tools?
Assess whether the combined setup can maintain the records, traceability and controls your process requires. Decide where each record belongs, which system holds its approved version and who resolves inconsistencies, then evaluate integrations against that design.
What validation information should we request from a supplier?
Request the supplier's validation approach, available evidence and the assumptions behind it, then agree which activities and records each party provides for your intended use, configuration and integrations. The FDA's computer software assurance guidance describes a risk-based approach for software used in device production or the quality system. It concerns those supporting systems, not the medical-device software you develop.
Who makes the regulated decisions when an IMSQ expert is involved?
You retain responsibility for your QMS and regulated decisions. IMSQ's advisory boundary reads:
IMSQ provides training infrastructure and facilitated access to independent Experts. Final regulated decisions remain the customer's responsibility under their own QMS.
Bring one software-quality problem to an IMSQ program review
If your team has the tools but still needs help deciding, doing or learning, book a free 30-minute IMSQ program review. Bring one development-planning, requirements or traceability problem.
Sources checked on 29 September 2026 against official standards-body, FDA and EU material and suppliers' public product pages. IMSQ has no commercial relationship with the software suppliers named.