What ISO 13485 actually is, why it is the critical path item for any Class IIa+ DMHT product, the clauses most relevant to SaMD, how it interacts with ISO 14971 and DCB0129, and what a minimum viable QMS looks like for a small DMHT manufacturer.
Common issues: ISO 13485 is treated as a documentation task to complete before Approved Body submission, when in fact it is an operational system that must be running six to twelve months beforehand and underpins the defensibility of every other regulatory output.
ISO 13485 is the international quality management system standard for medical device manufacturers. It specifies the requirements for a QMS that demonstrates a manufacturer's ability to consistently provide medical devices that meet customer and regulatory requirements.
It is not a product standard. It does not certify the device.
It certifies that the organisation has a system in place to design, develop, produce and improve the device in a controlled and documented way.
ISO 13485 is derived from ISO 9001 but is more prescriptive and includes medical device-specific requirements that ISO 9001 does not cover. Holding ISO 9001 certification does not satisfy ISO 13485.
They are separate certifications.
Any manufacturer placing a Class IIa or above medical device on the UK or EU market requires a certified ISO 13485 QMS before an Approved Body will conduct a conformity assessment. Class I manufacturers are not required to hold third-party certification but are required to have a QMS in place that meets the standard's requirements.
Four points about how the certification process actually works.
The standard is not reproduced here in full.
Establish, document, implement, maintain and continually improve a QMS. This includes a quality manual, documented procedures, and records demonstrating implementation.
The most detailed clause for DMHT products. Covers planning of product realisation, customer-related processes, design and development controls (inputs, outputs, review, verification, validation and transfer), purchasing controls (supplier qualification for AI models, cloud infrastructure and third-party components), and production and service provision controls.
Requires design and development planning, inputs, outputs, review, verification, validation and change control. For DMHT products this maps directly onto the software development lifecycle requirements in IEC 62304.
The two standards should be implemented together: IEC 62304 provides the software-specific process requirements; ISO 13485 clause 7.3 provides the QMS framework within which those processes operate.
Requires monitoring and measurement of product and process performance, internal audits, control of nonconforming product, corrective and preventive action. For DMHT this includes post-market surveillance data feeding back into the risk management file and triggering corrective actions where needed.
Three standards, one integrated process.
ISO 13485 is the QMS framework. It specifies that certain processes must exist and be controlled.
It does not prescribe what those processes must produce in terms of specific documents or risk analysis outputs.
ISO 14971 is the risk management standard. It operates within the ISO 13485 QMS.
The risk management plan, hazard log, risk management report and post-market surveillance activities that ISO 14971 requires are all produced under ISO 13485 controlled processes. Without the QMS, the risk management outputs are not produced under a controlled system and their evidentiary value is weakened accordingly.
DCB0129 is the NHS clinical safety standard. It embeds the ISO 14971 risk management process and adds NHS-specific requirements: a named certified Clinical Safety Officer, a Clinical Safety Case Report, a Clinical Risk Management Plan, and specific documentation for DTAC C1 submission.
DCB0129 compliance does not require ISO 13485 certification. A product can be DCB0129 compliant and DTAC-ready without an ISO 13485 certified QMS.
However, a product cannot achieve Approved Body conformity assessment for UKCA or CE marking without ISO 13485 certification, regardless of how thorough the DCB0129 documentation is. The two pathways are independent and must both be completed for a product entering NHS procurement via formal contract and pursuing UKCA marking simultaneously.
The ISO 13485 certification process runs in sequence.
The Approved Body reviews the QMS documentation to assess whether it meets the standard's requirements on paper. This is a desk-based review.
The outcome is either readiness for Stage 2 or a list of gaps to address before proceeding.
The Approved Body conducts an on-site or remote audit of the QMS in operation. Staff are interviewed.
Records of decisions made under the QMS are reviewed. Procedures are checked against practice.
The outcome is either certification, certification with conditions, or a list of major and minor nonconformities to address.
Once certified, the QMS is subject to annual surveillance audits by the Approved Body to confirm it remains compliant and continues to be operated effectively. Recertification audits occur every three years.
For DMHT products the Approved Body conducting QMS certification is typically the same body that will conduct the technical file conformity assessment. Engaging the Approved Body early, before the QMS is complete, to agree the audit scope and timeline is standard practice and prevents the queue time delays that arise from late engagement.
A small DMHT manufacturer typically implements the QMS using a combination of a quality management platform or document control system, a design history file for the product, and a series of standard operating procedures covering the key processes. The minimum viable QMS for a Class IIa DMHT product typically covers the following process areas: document and record control, design and development, software development lifecycle (referencing IEC 62304), risk management (referencing ISO 14971), clinical evaluation, usability engineering (referencing IEC 62366), supplier management, corrective and preventive action, internal audit, and management review.
For a SaMD product with an AI component, the QMS must also cover the PCCP process, model change control, and post-market surveillance activities that feed back into the risk management file. These are the areas where Approved Bodies most frequently identify gaps in DMHT QMS implementations.
The quality manual is the document that describes the QMS scope, the interaction between processes, and the reference to documented procedures. It is not a long document.
A quality manual for a small DMHT manufacturer is typically ten to twenty pages. Its function is to give the Approved Body auditor a map of the QMS, not to contain the QMS itself.
The processes that must be in place for Kova v1.0, the documents each process produces, and the interfaces between processes.
| QMS process area | Key documents produced | Interface with other processes |
|---|---|---|
| Document and record control | QMS Manual; SOP index; document control log; records retention schedule. | Underpins every other process; all procedures and records are controlled under it. |
| Design and development (clause 7.3) | Design and Development Plan; Design Inputs; Design Outputs; Design Reviews; Verification and Validation reports; Design Transfer record; Design History File. | Receives requirements from clinical evaluation and risk management; feeds verification and validation evidence into the technical file. |
| Software development lifecycle (IEC 62304) | Software Development Plan; software requirements; architecture; unit and integration test records; SOUP list; release records. | Operates inside Design and Development; feeds defect data into CAPA and post-market surveillance. |
| Risk management (ISO 14971 / AAMI TIR34971) | Risk Management Plan; Hazard Log; Risk Management Report; PMS-to-risk feedback log. | Inputs to design and development and to clinical evaluation; receives PMS data and CAPA outputs. |
| Clinical evaluation | Clinical Evaluation Plan; Clinical Evaluation Report; literature search records. | Inputs to risk management and intended purpose; feeds clinical claims into the technical file. |
| Usability engineering (IEC 62366) | Use Specification; Use Error Analysis; Formative and Summative Evaluation reports. | Inputs to risk management; outputs feed design changes via CAPA. |
| Supplier management (clause 7.4) | Approved Supplier List; supplier qualification records; supplier agreements (foundation model provider, cloud, third-party libraries). | Feeds into Design and Development for SOUP and AI components; supplier issues trigger CAPA. |
| Corrective and preventive action | CAPA log; root cause analysis records; effectiveness checks. | Receives inputs from PMS, internal audit, complaints and nonconforming product; feeds changes back into design and risk. |
| Internal audit | Internal audit schedule; audit reports; nonconformity log. | Triggers CAPA; informs management review. |
| Management review | Management review inputs and minutes; action log. | Reviews outputs from all processes; assigns resources and approves QMS changes. |
| Post-market surveillance (SaMD AI overlay) | PMS Plan; PMS Reports; drift monitoring records; PCCP execution log. | Feeds risk management, CAPA and design changes; supports periodic safety updates. |
Form your own view first. Reveal the reference answer to compare reasoning.
A manufacturer is developing a Class I SaMD (a symptom diary that records user-entered data and presents it back; no diagnosis, no treatment recommendation). The founder has budgeted £80,000 and nine months for Approved Body ISO 13485 certification before launch, on the assumption that certification is required. What is the correct advice?
A Class IIa DMHT product is twelve months from intended commercial launch. The technical file is complete, the risk management file is signed by a certified CSO, the clinical evaluation report has been finalised. There is no QMS in place: development has been managed through ad-hoc project documentation. The founder asks whether ISO 13485 work can begin now and be ready for Approved Body submission six months before launch. Assess the timeline.
A manufacturer is six weeks from Stage 2 audit. The product integrates a third-party LLM via API. The supplier was selected on engineering preference; there is no supplier qualification record, no supplier agreement on file specific to medical device use, no documented controls on the interface between the product and the model, and no evidence of evaluation against ISO 13485 clause 7.4. What is the correct remediation before audit?
Educational resource. Not formal regulatory or legal advice.
