Medical Device Quality Management Software: ISO 13485 and QMSR
A Full-Lifecycle Quality Management System for Medical Device Manufacturers
Medical Device QMS Software
A Full-Lifecycle Quality Management System for Medical Device Manufacturers Who Have Products in Market and Cannot Afford Compliance Gaps
Your device has 510(k) clearance or PMA approval. You have manufacturing procedures, a supplier qualification programme, incoming inspection records, and a complaint handling process. The regulatory framework that governs your QMS has been in place for years. The problem is not what the system requires. The problem is how much of your quality team’s week is spent maintaining compliance evidence rather than managing quality.
A quality manager at a mid-market medical device manufacturer is not building a QMS from scratch. They are running one — managing open CAPAs, coordinating internal audits, reviewing DHR completeness before shipment, responding to supplier deviations, and ensuring that every process change triggers the training and document update sequence the regulation requires. The administrative burden of that work, in systems that were not designed to enforce the workflow, is where compliance gaps form.
eLeaP is a medical device QMS that operationalizes both ISO 13485:2016 and 21 CFR Part 820 — now transitioning to the Quality Management System Regulation (QMSR) — as enforced workflow, not as a document library. The clauses that create your compliance obligations are mapped to system functions that run the process, create the records, and build the audit trail without requiring your quality team to be the enforcement mechanism.
The medical device QMS software market is heavily weighted toward startups in the design phase. eLeaP is built for manufacturers with established products in market who need a system that handles the operational complexity of a running quality programme — not just the documentation structure of an initial certification.
The Regulatory Framework: ISO 13485:2016 and 21 CFR Part 820 / QMSR
Medical device quality management is governed by two primary frameworks. Understanding both — and how they interact — is essential context for evaluating QMS software that must satisfy both simultaneously.
ISO 13485:2016
ISO 13485:2016 is the international standard for quality management systems specific to medical devices. It is the basis for regulatory submissions and market access in the European Union under the Medical Device Regulation (MDR), in Canada, Australia, Japan, and most markets outside the United States. ISO 13485 is more prescriptive than ISO 9001 in several areas: it requires a quality manual, it mandates documented procedures for a defined set of processes, and it places specific requirements on risk management throughout the product lifecycle.
The clauses most directly supported by QMS software capabilities are Section 4.2 (documentation requirements), Section 7.3 (design and development), Section 8.2 (monitoring and measurement), Section 8.3 (control of nonconforming product), and Section 8.5 (improvement — including CAPA). Each of these sections creates documented workflow obligations that a compliant QMS must satisfy and that a certification body auditor will verify.
21 CFR Part 820 and the QMSR Transition
21 CFR Part 820 has been the FDA’s Quality System Regulation for medical device manufacturers since 1996. The FDA has finalized the Quality Management System Regulation (QMSR), effective February 2, 2026, which replaces the original Part 820 framework with a structure substantially aligned to ISO 13485:2016. The practical effect for manufacturers is that compliance with ISO 13485:2016, properly implemented and documented, largely satisfies QMSR requirements — but several FDA-specific obligations remain, including the Device History Record requirements under 21 CFR Part 820.184 and the training procedure requirements under 21 CFR Part 820.25.
eLeaP is structured to satisfy both frameworks. The platform supports ISO 13485:2016 clause requirements as documented workflow processes while maintaining the specific record types and traceability requirements that QMSR and its predecessor Part 820 impose. Manufacturers operating under both frameworks — submitting to FDA while maintaining CE marking under MDR — can manage both compliance obligations from a single system without maintaining parallel quality records.
ISO 13485:2016 Clause by Clause: Requirements and eLeaP Capabilities
Section 4.2 — Documentation Requirements
ISO 13485 Section 4.2 requires that the QMS include a quality manual, documented procedures required by the standard, documents needed by the organization to ensure effective planning, operation, and control of its processes, and records required by the standard. Unlike ISO 9001:2015, ISO 13485 retains the quality manual requirement and mandates documented procedures for a defined list of processes. Section 4.2 also requires document control procedures that govern approval, review, update, identification of revision status, availability at points of use, legibility, and control of obsolete documents.
eLeaP’s document control module addresses each Section 4.2 requirement as a system function. Documents are created within defined templates, routed through configured approval workflows, and published with controlled access that ensures users receive only current approved versions. Revision history is maintained automatically. Obsolete versions are retained in a segregated archive with the date of obsolescence recorded. When a document is revised, eLeaP identifies every role whose work the document governs and generates retraining assignments — closing the Section 4.2 distribution and awareness gap that static document libraries cannot enforce.
Section 7.3 — Design and Development Controls
ISO 13485 Section 7.3 is the clause that most differentiates medical device QMS from general manufacturing quality management. It requires documented procedures for design and development, covering planning, inputs, outputs, review, verification, validation, transfer, changes, and design history file maintenance. Each design stage requires documented evidence: design inputs must capture functional, performance, and safety requirements; design outputs must be verifiable against inputs; design reviews must involve qualified representatives of each function; verification must confirm outputs meet inputs; validation must confirm the device meets user needs under conditions of intended use.
The Design History File (DHF) is the documentation artifact that contains or references all records generated by the design control process. FDA investigators reviewing a 510(k) submission or conducting a facility inspection will examine the DHF for completeness and traceability — confirming that every design change was reviewed, that verification and validation activities were performed and documented, and that the design transfer to manufacturing was formally completed.
eLeaP’s design control module structures the DHF as a living record that is built progressively through the design process rather than assembled retrospectively before a submission. Design planning records, inputs, outputs, review minutes, verification protocols and results, validation protocols and results, and transfer documentation are all managed within the platform and linked to the DHF record. Design changes after initial release follow a controlled change procedure that requires impact assessment, review, and re-verification or re-validation where the change affects design outputs.
Greenlight Guru built their market position on design controls for early-stage startups navigating their first 510(k). eLeaP serves the manufacturer that already has a cleared or approved device and needs design change control, post-market surveillance integration, and the operational quality infrastructure that maintains compliance across the full product lifecycle — not just the pre-market submission phase.
Section 8.2 — Monitoring and Measurement
ISO 13485 Section 8.2 requires that the organization monitor information relating to whether customer requirements have been met, using this information as a measurement of QMS performance. It requires procedures for complaint handling, reporting to regulatory authorities, and internal audit. Section 8.2 creates the post-market surveillance obligation that connects field complaints to the internal quality system — requiring that complaints be reviewed to determine whether they constitute reportable events under applicable regulations and whether they require CAPA initiation.
eLeaP’s complaint management workflow captures complaints at intake with structured classification fields: the product, lot or serial number, the nature of the complaint, whether the device was involved in a serious injury or death, and whether a malfunction could cause or contribute to a serious injury if it were to recur. Classification triggers the regulatory reporting evaluation — a documented determination that the complaint was or was not reportable under applicable MDR, MDR equivalents, or other market-specific requirements. The determination and its supporting rationale are part of the complaint record.
Internal audit requirements under Section 8.2 are addressed through eLeaP’s audit management module, which supports the full audit programme from scheduling through finding closure. Audit programmes are built against the ISO 13485 clause structure, with audit results linked to the CAPA workflow for findings that require corrective action.
Section 8.3 — Control of Nonconforming Product
ISO 13485 Section 8.3 requires documented procedures for the control of nonconforming product, covering identification, documentation, evaluation, segregation where practical, and disposition. For medical devices, disposition decisions must be made by designated individuals and documented, and concessions — decisions to use or release nonconforming product — require justification and approval by the appropriate authority. Where nonconforming product is detected after delivery, the organization must take action appropriate to the consequences, including investigation and potential regulatory notification.
eLeaP’s nonconformance management module enforces each Section 8.3 requirement as a gated workflow step. Nonconformances are captured, classified, and routed for investigation. Disposition decisions are required before the record can advance to closure. Use-as-is and rework dispositions require additional approval. Post-delivery nonconformances — field complaints and returns — trigger the complaint handling workflow and the regulatory reporting evaluation. The closed nonconformance record provides the documentation that Section 8.3 requires the procedure to produce.
Section 8.5 — Improvement, CAPA, and Preventive Action
ISO 13485 Section 8.5 requires procedures for both corrective action and preventive action — with separate and documented requirements for each. Corrective action addresses the root cause of a detected nonconformity to prevent recurrence. Preventive action addresses the cause of a potential nonconformity to prevent occurrence. Section 8.5 requires that both types of action be commensurate with the risk of the nonconformity encountered or the potential problem, and that the effectiveness of each action be reviewed and documented.
eLeaP’s CAPA module supports the full Section 8.5 lifecycle: initiation from a nonconformance, audit finding, complaint, or risk assessment; root cause analysis with structured category fields; corrective or preventive action planning with assigned owners and target dates; implementation tracking; and effectiveness verification with a documented review at a defined interval after action completion. CAPA records are bidirectionally linked to their originating quality events, creating the traceability from problem identification through verified resolution that Section 8.5 requires.
Related resource: CAPA Management Software — the complete corrective and preventive action lifecycle from initiation through effectiveness verification.
Design Controls for Established Products: Change Management, Not Just Initial Development
The majority of QMS software marketed for medical device design controls is positioned for the startup navigating its first regulatory submission. The design control workflow is framed around building the DHF from scratch and producing the documentation package that supports a 510(k) or PMA application.
Mid-market medical device manufacturers with established products in market have a different design control challenge. The initial DHF exists. The product is cleared or approved. The design control requirement that generates the most compliance work — and the most inspection risk — is not the initial development workflow. It is the change control process that governs every modification to the product, its specifications, its manufacturing process, or its labeling after initial release.
Design Change Control Under ISO 13485 Section 7.3.9
ISO 13485 Section 7.3.9 requires that design and development changes be identified, documented, reviewed, verified or validated as appropriate, and approved before implementation. Changes must be evaluated for their effect on the constituent parts and product in process or already delivered. This evaluation — whether a change requires new verification, new validation, or a regulatory submission — is the determination that an FDA investigator will scrutinize when reviewing your design change records.
eLeaP’s design change workflow enforces Section 7.3.9 as a documented process. Each change request captures the nature of the change, the rationale, and the affected design documents or specifications. The impact assessment step determines whether the change is a design change requiring re-verification or re-validation, or an administrative correction. Changes classified as requiring verification or validation are routed through the appropriate technical review before approval. Changes that may trigger a regulatory submission obligation — new intended use, new safety risk, change affecting substantial equivalence — include a regulatory affairs review step.
Every design change approved in eLeaP updates the DHF record with the change documentation, maintains the complete revision history of the design, and links the change to any associated validation records, CAPA records, or supplier qualification updates that the change requires. The DHF is always current and always traceable — without manual document assembly.
Post-Market Design Input: Closing the Feedback Loop
ISO 13485 Section 8.2 requires that post-market data — complaints, service records, adverse event reports, and literature surveillance findings — be evaluated for implications on the product design. This requirement creates a connection between the quality events happening in the field and the design control process that governs the product. A pattern of complaints about a specific component’s reliability is a design input. A recurring service issue caused by user interface confusion is a design input. An adverse event that reveals a previously unidentified use scenario is a design input.
eLeaP connects complaint and nonconformance records to the design change workflow through the CAPA and change initiation pathway. When post-market quality data identifies a design-related root cause, eLeaP can initiate a design change review from the quality event record — creating a documented chain from field observation through design investigation to design change decision. This traceability is what the FDA describes as an effective post-market surveillance system, and it is the evidence that inspectors look for when they evaluate the connection between your quality system and your design history.
Device History Record: What 21 CFR Part 820.184 Requires and How eLeaP Supports It
21 CFR Part 820.184 requires that each manufacturer maintain a Device History Record for each type of device. The DHR must contain or reference the dates of manufacture, quantity manufactured, quantity released for distribution, acceptance records, labeling, and device identification. The DHR is the manufacturing record that proves a specific device unit or lot was produced in conformance with its Device Master Record (DMR). When an FDA investigator reviews a DHR, they are confirming that the manufacturing documentation reflects an actual production event that followed approved procedures.
DHR completeness is one of the most frequent 483 observation categories in medical device facility inspections. Common gaps include missing acceptance records for in-process inspections, incomplete traceability between lot numbers and component batch records, labeling records that do not match the version used at time of manufacture, and training records that do not confirm all production personnel were qualified at the time the device was manufactured.
eLeaP supports DHR completeness and traceability across several dimensions. Manufacturing batch records link to incoming inspection records for the components used in that production run. In-process inspection results are captured and linked to the batch. Final release acceptance is documented with the approving individual’s credentials and the date. Nonconformances affecting the batch are linked to the batch record with their disposition outcomes. And critically — the training records for the personnel who manufactured the device are accessible from the batch record, confirming their qualification at the time of production.
DHR completeness is not just a documentation exercise. It is the manufacturing evidence that establishes each device was produced as designed. When a field complaint triggers an investigation that leads back to a production batch, the DHR is the record that either supports your response or creates your exposure.
Training as a Regulatory Requirement, Not an Administrative Function
21 CFR Part 820.25 requires that each manufacturer establish procedures for identifying training needs and ensuring that all personnel are trained to adequately perform their assigned responsibilities. Training records are part of the Device History Record — they are not a separate administrative function. When an investigator reviews a DHR and asks whether the operator who ran the process was trained and qualified, the training record must answer that question with a dated, role-specific completion record that ties to the specific procedure version in effect at the time of manufacture.
In most medical device QMS platforms, training is managed separately — through a standalone LMS, through a training coordinator’s spreadsheet, or through a sign-off sheet attached to a document revision. The training record exists in a different system from the quality event that required it, and connecting them requires manual cross-referencing that becomes impossible to maintain at scale.
eLeaP eliminates that separation. When a document is revised in eLeaP, the platform automatically identifies every role governed by that document and generates training assignments tied to the new version. When a nonconformance or CAPA identifies a training gap as root cause, eLeaP automatically generates retraining assignments for the affected roles. When a design change affects manufacturing procedures, the retraining assignments for production personnel are generated as part of the change implementation workflow. Training completion records are stored in the same platform as the quality events that triggered them — and they are available without reconstruction when a DHR review or an inspection demands them.
No other medical device QMS competitor offers this integration natively. Greenlight Guru, MasterControl, and Veeva QualityOne offer training management in the sense of document sign-off and completion logging. They do not offer enterprise-grade learning management — course authoring, structured learning paths, competency assessments, role-based assignment logic — integrated with the quality event workflow that triggers the training requirement. That capability is what eLeaP brings from twenty years of LMS development, unified with the QMS in a single platform.
Related resource: QMS with Native LMS Integration — why the unified architecture delivers what integrated systems cannot for quality-driven training compliance.
Supplier Controls: ISO 13485 Section 7.4 and the Extended Quality System
ISO 13485 Section 7.4 requires that the organization evaluate and select suppliers based on their ability to supply product in accordance with requirements. The extent of supplier controls must be proportionate to the risk associated with the medical device and to the type of product supplied. Documented supplier qualification records, periodic re-evaluation, and defined criteria for acceptable supplier performance are all Section 7.4 requirements that an auditor will review when examining your supplier quality programme.
eLeaP’s supplier management module supports the Section 7.4 lifecycle. Supplier qualification records are maintained in the platform with the qualification criteria, evaluation results, and approval status. Re-evaluation schedules are system-managed — the platform generates re-qualification reviews at defined intervals without requiring the quality team to track them manually. Nonconformances originating from supplier material are linked to the supplier record, giving quality managers real-time visibility into supplier performance trends that support the risk-based supplier control decisions the standard requires.
For critical suppliers — contract manufacturers, sterilization service providers, and component suppliers whose products directly affect device safety or performance — eLeaP supports supplier audit scheduling and finding management within the same audit framework used for internal audits. Supplier audit findings can trigger CAPA records that are linked to the supplier quality record, creating the documented improvement cycle that a notified body or FDA investigator expects to see when reviewing your approach to high-risk supplier management.
Preparing for the QMSR Transition
The FDA’s Quality Management System Regulation became effective February 2, 2026, replacing the original 21 CFR Part 820 framework with a structure substantially harmonized with ISO 13485:2016. The transition has direct implications for manufacturers who were previously maintaining separate compliance postures for FDA and international markets: QMSR alignment with ISO 13485 means a single documented QMS can now satisfy both frameworks more directly than was previously possible under the original Part 820 structure.
The practical implications of the QMSR transition for manufacturers managing their QMS in eLeaP include several areas worth examining. QMSR adopts ISO 13485’s approach to design controls and risk management, requiring that risk management be integrated throughout the product lifecycle rather than treated as a discrete phase in development. QMSR retains several FDA-specific requirements — including DHR documentation under 820.184, complaint handling and MDR reporting, and the corrective and preventive action structure — that manufacturers must continue to satisfy regardless of ISO 13485 alignment.
eLeaP is structured to support QMSR compliance from the same platform that supports ISO 13485. The risk management integration, design change control, DHR traceability, and training record requirements that QMSR creates are all addressed as system functions. Manufacturers using eLeaP do not need to implement separate processes for QMSR compliance — the platform’s workflow structure satisfies both frameworks simultaneously.
Built for Operational Scale, Not Startup Simplicity
The medical device QMS software market has bifurcated. One segment serves early-stage startups building their first device — companies that need a simple, affordable QMS framework to support their initial submission and have minimal operational complexity. The other segment serves established manufacturers with multiple product lines, distributed manufacturing, complex supplier networks, and quality systems that must satisfy multiple regulatory frameworks across multiple markets simultaneously.
eLeaP serves the second segment. The quality team at a 150-person contract manufacturer of Class II devices has different software requirements than a 10-person startup pursuing a 510(k) for its first product. They need a system that handles the operational complexity of managing hundreds of open documents, dozens of active CAPAs, a multi-site internal audit programme, a supplier qualification portfolio spanning critical and non-critical suppliers, and a complaint handling workflow that connects to regulatory reporting obligations in multiple markets.
eLeaP is configurable to that complexity without requiring IT customization. Workflow configurations, document hierarchies, approval routing logic, audit programme structures, and training assignment rules are all managed through the platform’s configuration interface by quality professionals, not by software developers. The system adapts to the complexity of the manufacturing operation — not the other way around.
Related resource: Configurable Medical Device QMS — how eLeaP’s QMS adapts to multi-site operations, multiple product lines, and multiple regulatory frameworks.
The Inspection Is Not the Goal. The System Is.
A medical device quality management system that is built for inspections — structured to produce evidence on demand rather than to enforce the process that generates compliant outcomes — is a QMS that is perpetually fragile. It passes inspections when the quality team works hard enough. It fails when it does not.
eLeaP is built for the quality system that generates compliant outcomes by design. Document changes trigger training. Nonconformances enforce investigation before closure. CAPAs track to verified effectiveness. Design changes route through the impact assessment that Section 7.3.9 requires. DHRs are built progressively through the manufacturing process rather than assembled before shipment. Training records are part of the quality system record, not maintained in a separate system that must be reconciled on demand.
The result is a quality management system that satisfies ISO 13485:2016 and the QMSR not because the quality team enforces it, but because the platform enforces it. The audit trail builds itself. The gaps that generate 483 observations close before they open. The quality team manages quality — not the compliance evidence that quality is supposed to produce.