ISO 13485 software: what applies to software companies?
If your software company makes software with a medical use, your client will often expect an ISO 13485 system. This applies especially to software as a medical device (SaMD), such as an app that supports a diagnosis or calculates a dose. The standard itself is published by ISO . You determine whether your software falls under the European Medical Device Regulation (MDR) and in which class by following the MDR risk classes, with rule 11 as the main rule for software. How you secure this in an ISO 13485 handbook and the rest of your quality management system (QMS) is covered further on.
ISO 13485 does not make your software safe, and it is not a CE marking. It is the management system that shows how you develop, test and change your software. The law determines what you must demonstrate.
Two sides of software and ISO 13485
Within ISO 13485, the word “software” can mean two things. They require different approaches:
- Software as a medical device: the software itself is the product. Then design and development controls, risk management and validation apply to the product.
- Software that supports your QMS: you use a tool for documents, CAPA or complaints. You must validate that tool for its use. We cover this side in choosing QMS software.
Many software companies have both. Start with the first side: it determines what your client actually wants to see.
Which requirements are the heaviest for software companies?
The standard is technology-neutral, but a few parts come back more strongly with software:
- Design and development control (clause 7.3): you record design requirements, verify them and validate the final result.
- Risk management according to ISO 14971: software faults can cause harm directly, so the risk analysis belongs in every release.
- Change control: every code change that affects medical behaviour gets an assessment and a record.
- Validation of the software you use yourself: your build, test and QMS tools must also be validated to a suitable degree.
- Traceability of requirements to tests: an auditor wants to be able to follow a requirement to a test and back.
For the development process of medical software, IEC 62304 is often used as a supporting standard (IEC 62304:2006 with amendment A1:2015). It describes the software lifecycle. Use it as your working method. ISO 13485 requires proof that you actually do it.
Step by step: from idea to an audit-ready software process
Determine the intended use and the class
Write in one paragraph what the software does, for whom, in which situation and with which risk. That text is the basis for everything else. Without a clear intended use, you cannot determine the class.
Record the design requirements
Make a list of requirements that follow from the intended use. Think of accuracy, availability, use errors and connections with other systems. Each requirement gets a number.
Link requirements to verification and validation
Verification asks: did we build it right, according to the requirements? Validation asks: did we build the right thing, for the user? For each requirement, record which test proves it has been met.
Set up change control
Every change to the code that could affect the behaviour of the device goes through an assessment. Minor changes, such as a text in the interface, need less. Decide in advance what you call minor and what you call major.
Manage the release
A release has a version, a release record, the test results and a decision by an authorised person. Without that record, an auditor cannot establish which software was supplied to which client.
Example: a change in a symptom checker
A fictional example. A software company makes an app that uses symptoms to indicate whether a patient should see a GP quickly. The team wants to change the threshold value for a certain symptom.
| Step | What do you record? | Who decides? |
|---|---|---|
| Description of the change | Old and new threshold value, reason, source of the change | Product owner |
| Risk assessment | Which extra false negatives or false positives are possible | Quality and clinical adviser |
| Test plan | Test cases that cover the new threshold and the limit values | Test lead |
| Validation | Test results and deviations, with a decision | Quality manager |
| Release | Version, release notes, decision to roll out | Authorised management |
If you see no role for quality in this table, there is a gap. The auditor will ask about exactly that.
Common mistakes at software companies
- An agile process without evidence. Fast sprints are fine, but each sprint must produce records that link requirements and tests.
- No distinction between medical and non-medical behaviour. If a function affects medical behaviour, it falls under the system, even if it seems small.
- Forgetting to validate tools. The CI pipeline (the automated build and test environment) and the ticketing system count if you use them to decide on a release.
- A one-off risk analysis. Each change requires a review.
- Starting too late. Many teams build first and document later. With an auditor, that often costs months.
Start small and choose the right order
A small software team does not have to arrange everything at once. Start with the intended use, the class and the requirements. Then come risk management and change control. You build the QMS around them. For the minimum system at a start-up, read ISO 13485 for medtech start-ups.
Under rule 11, decision-support software usually falls into class IIa at a minimum. Then a notified body (a designated conformity assessment body) assesses your technical file. See choosing a notified body for the choice and the cost of an assessment.