FDA Design Controls Software: All Nine QMSR Design Control Elements, the Design History File, and Post-Market Design Changes in a Full QMS Suite

FDA design controls are the documented procedures, records, and review activities that regulated medical device manufacturers must maintain throughout the full lifecycle of each device — from initial design planning through post-market design changes. Under the Quality Management System Regulation (QMSR), which took effect February 2, 2026, design control requirements are embedded in the ISO 13485:2016 framework that QMSR adopts by reference. The specific design control requirements that FDA has maintained — covering design planning, inputs, outputs, review, verification, validation, transfer, and change — align with ISO 13485 Section 7.3 sub-clauses. These obligations do not end at 510(k) clearance or PMA approval. They apply to every subsequent change to a cleared or approved device and scale with the product across its commercial lifecycle.

Some design control platforms treat design controls as a bounded development-phase activity — a set of procedures and documents that apply from concept to clearance and then go into maintenance mode. That framing does not reflect the regulatory obligation. Design controls under the QMSR and ISO 13485 Section 7.3 are a continuous obligation. The design history file must be maintained through every post-market design change. Every change to a cleared device requires a design change control assessment. A CAPA that identifies a design-related root cause initiates a design change. A complaint that reveals a use environment problem triggers a design review. The design control system in a medical device company scales with the product lifecycle — it does not end at launch.

eLeaP addresses design controls within a full QMS suite: connected to production quality, supplier management, complaint handling, CAPA, training, and change control. This page covers all QMSR design control elements — their regulatory basis, their documentation requirements, and how eLeaP addresses each one — along with the Design History File architecture, the traceability matrix structure, and how post-market design changes connect to the rest of the quality system.

Regulatory Basis: QMSR Design Controls and ISO 13485 Section 7.3

The Quality Management System Regulation (QMSR), effective February 2, 2026, establishes the current design control requirements for medical device manufacturers subject to FDA jurisdiction. The QMSR incorporates ISO 13485:2016 by reference as the foundational quality management framework and aligns US design control requirements with the ISO 13485 Section 7.3 structure. For manufacturers operating in both US and international markets, satisfying ISO 13485 Section 7.3 addresses the QMSR design control requirements, with FDA’s implementation guidance providing additional specificity in certain areas.

The QMSR requirement for design controls applies to each manufacturer whose devices are designed or subject to design changes. Manufacturers must establish and maintain design control procedures to ensure that specified design requirements are met. The requirement applies not only to original device design but to any subsequent design change — a critical point for established manufacturers with cleared or approved devices who may assume design controls are a development-phase obligation rather than a lifecycle obligation.

References to 21 CFR Part 820.30 in device technical files, DHF documentation, and historical records reflect the prior regulatory structure that QMSR superseded. Manufacturers maintaining DHF records from pre-QMSR design cycles retain those records under their original citation structure; new design activities and design change records initiated on or after February 2, 2026 are conducted under the QMSR framework.

All Nine QMSR Design Control Elements: What Each Requires and How eLeaP Addresses It

The QMSR design control requirements — carried forward from 21 CFR 820.30 and now structured within the ISO 13485 Section 7.3 framework — specify nine documentation and process elements. Each element has specific record requirements and specific record linkage requirements that design control software must support.

Element 1 — Design and Development Planning (ISO 13485 Section 7.3.2)

Design and development planning requires a plan that describes the design and development activities, responsibilities, and interfaces between different groups and individuals. The plan must be updated as the design evolves. ISO 13485 Section 7.3.2 requires the plan to identify the review, verification, and validation activities appropriate to each design and development stage, and to be updated as development progresses.

eLeaP: The design and development plan is a controlled document within the QMS document control module, version-controlled and updated through the change control workflow. The plan references the design review schedule, the verification and validation activities planned for each stage, and the responsible parties for each activity. As design stages are completed and the plan is updated, prior plan versions are archived in the document history. The DHF record links to the current plan version and to all prior versions, satisfying the requirement that the plan reflect design development progress.

Element 2 — Design Input (ISO 13485 Section 7.3.3)

Design input requirements address the requirements relating to the device, including physical, chemical, biological, mechanical, software, and use-environment requirements. Design inputs must be documented, and incomplete, ambiguous, or conflicting requirements must be resolved before design work begins. ISO 13485 Section 7.3.3 additionally requires that inputs include applicable regulatory and legal requirements and information derived from previous similar designs.

eLeaP: Design input records capture each requirement with its source — user need, regulatory requirement, risk control measure, or predecessor design reference. Incomplete or conflicting inputs are flagged at the record level and cannot be marked resolved without documenting the resolution. Design input records link to the risk management records that informed them, satisfying the requirement that inputs include risk controls derived from the risk management process. The design input record set forms the traceable foundation from which outputs, verification, and validation link.

Element 3 — Design Output (ISO 13485 Section 7.3.4)

Design output requirements address the total finished device design and its components, including relevant technical drawings, component specifications, software, labeling, and packaging. Design outputs must be expressed in terms that allow adequate evaluation of conformance to design input requirements. Each output must identify characteristics that are critical to the proper functioning of the device.

eLeaP: Design output records link explicitly to the design inputs they address, maintaining the input-to-output traceability that the traceability matrix requires. Critical characteristics are flagged at the output record level, ensuring they are addressed in verification and validation planning. Device Master Record documents — drawings, specifications, software requirements, labeling specifications — link from the design output records as controlled documents within the QMS document control module.

Element 4 — Design Review (ISO 13485 Section 7.3.5)

Design review requirements mandate formal documented reviews of design results at appropriate stages. Each review must be planned and conducted by individuals who include at least one person without direct responsibility for the design stage being reviewed. Design review records must include the date, participants, and review results, including any actions required.

eLeaP: Each design review is a quality record linked to the design stage it covers. The review record captures the participants, their roles, the design documents reviewed, the review findings, and the actions required before the next stage begins. The independent reviewer requirement is enforced at the review assignment stage — the design review record must include at least one reviewer who is not assigned to the design stage under review. Unresolved design review action items prevent stage advancement in the design control workflow.

Element 5 — Design Verification (ISO 13485 Section 7.3.6)

Design verification requirements mandate procedures confirming that design outputs meet design input requirements. Verification activities must be documented with the method, date, and results. ISO 13485 Section 7.3.6 adds that verification must be planned, that verification methods must confirm outputs meet input requirements, and that records of verification results must be maintained.

eLeaP: Verification records link to the specific design inputs they verify and to the design outputs being tested. Each verification record captures the verification method, the acceptance criteria, the test date, the tester identity, and the result. A verification result that does not meet acceptance criteria creates an open action that must be resolved before the verification stage can be closed. The traceability matrix view in the DHF shows, for each design input, whether the corresponding output has been verified, the verification method used, and the result.

Element 6 — Design Validation (ISO 13485 Section 7.3.7)

Design validation requirements mandate that manufacturers ensure devices conform to defined user needs and intended use. Validation must include testing under actual or simulated use conditions, performed on production devices or devices representative of production devices, and must be completed before commercial distribution. Clinical evaluation under 21 CFR Part 860.7 may be required to support validation for certain device types.

eLeaP: Design validation records link to the user needs and intended use statements that the validation is designed to confirm. Validation study records capture the test protocol, the device configuration used in validation, the test conditions, and the results. Clinical evaluation records link to the device record where applicable. The distinction between verification — confirming outputs meet inputs — and validation — confirming the device meets user needs — is maintained in the record structure, satisfying the regulatory requirement that both activities are documented separately.

Element 7 — Design Transfer (ISO 13485 Section 7.3.8)

Design transfer requirements mandate procedures ensuring that the device design is correctly translated into production specifications. Design transfer records must confirm that production methods can produce devices that meet the design requirements. This is the bridge between the design history file and the device master record: the transfer confirms that the DMR correctly implements the approved design.

eLeaP: The design transfer record links the final design output records to the corresponding DMR documents — manufacturing specifications, work instructions, process parameters, and acceptance criteria. The transfer review confirms that each design output has a corresponding production specification in the DMR and that the specification is achievable using available production methods. Transfer acceptance criteria include first article inspection results and process capability data where required. The design transfer record closes the design history file for the initial design cycle and opens the production quality record chain.

Element 8 — Design Changes (ISO 13485 Section 7.3.9)

Design change requirements mandate that all design changes be identified, documented, reviewed, and approved before implementation. This element applies throughout the product lifecycle — every change to the design of a cleared or approved device, regardless of how minor it appears, requires a design change control assessment. The assessment must determine whether the change requires new or additional verification and validation before implementation. Certain changes require FDA submission before implementation.

eLeaP: Design change records route through the change control workflow with a design control impact assessment that identifies the verification and validation implications of the proposed change. A change that affects a design output linked to a verified design input requires re-verification of that input-output pair. A change that affects a user need or intended use addressed in validation requires re-validation. The design change record links to the DHF records it modifies, and the modified DHF records carry a change history showing the design change that authorized each modification. Post-market design changes are covered in detail in the section below.

Element 9 — Design History File (ISO 13485 Section 4.2.5)

Design history file requirements mandate that a DHF be established and maintained for each type of device. The DHF must contain or reference the records necessary to demonstrate that the design was developed in accordance with the approved design plan and applicable regulatory requirements. A DHF that contains documents without demonstrating their connected relationship to each other and to the design plan does not satisfy this requirement — the records must be navigable in the context of the design they document.

eLeaP: The DHF in eLeaP is a navigable record network rooted in the device record. The design plan links to each stage’s activities. Design inputs link to the outputs they drove. Outputs link to the verification tests that confirmed them. Verification records link to the validation studies where validation is built on verified outputs. Design review records link to the design stage they reviewed. Design change records link to the DHF records they modified. An auditor navigating the eLeaP DHF can follow any traceability path — from user need to design input to design output to verification to validation to production specification — within the quality system without assembling documents from multiple locations.

The Design History File as a Connected Record Set, Not a Document Collection

The most common DHF compliance gap in Notified Body and FDA audits is not missing documents. It is missing connections. The auditor can find a design input record and a verification test record but cannot trace the relationship between them. They can find a complaint record and a design change record but cannot confirm that the complaint drove the change. The documents exist in the file. The traceability does not exist in the file.

A SharePoint folder, a Google Drive, or a standalone electronic document management system manages documents. It does not maintain record relationships. When an auditor asks to see the verification evidence for a specific design input, the answer from a document-management DHF is a search that may or may not locate the right test report. The answer from eLeaP’s record-network DHF is a direct navigation from the design input record to its linked verification records, with the acceptance criteria and results visible without leaving the device record view.

Every record in the eLeaP DHF carries explicit links to the records it connects to. Design inputs link to their source — user need, regulatory requirement, risk control — and to the outputs that address them. Outputs link to the inputs they address and to the verification tests that confirm them. Verification tests link to the outputs tested and the inputs verified. The links are system-maintained record relationships, not manual hyperlinks in documents that can drift or break when records are modified.

Traceability Matrix: System-Maintained Linkage vs. Manual Spreadsheet

The design control traceability matrix maps each user need to the design input that addresses it, to the design output that implements the input, to the verification test that confirms the output meets the input, and to the validation study that confirms the device meets the user need. In most medical device companies, this matrix is a manually maintained spreadsheet. It is created at some point in the development cycle, updated inconsistently as changes are made, and does not reflect the current state of the DHF at the time of an audit.

In eLeaP, the traceability matrix is a live query of the record relationships in the DHF. Because each record type carries its links as part of the record structure, the traceability view can be generated at any time and will always reflect the current state of the DHF. When a design change modifies an output, the traceability view immediately reflects that the verification for that output may need to be updated. When a new design input is added, the traceability view shows it as unverified until a verification record is linked. The matrix is not a document that requires manual maintenance — it is a view of the record network that maintains itself through the record-linking architecture.

For Notified Body audits, the traceability matrix generated from eLeaP demonstrates design control traceability without requiring the quality team to assemble a new matrix for each audit. The most current version of the matrix reflects the most current state of the DHF. Gaps in traceability — design inputs without linked outputs, outputs without linked verification tests, verification tests that did not meet acceptance criteria — are visible in the matrix view and can be addressed before the audit rather than being discovered during it.

Post-Market Design Changes: Connecting QMSR Design Change Requirements to the Full QMS

Post-market design changes are where the integration between design controls and the broader quality management system becomes most visible. A design change triggered by a CAPA connects the design history file to the quality event that drove the change. A design change that affects production methods connects the DHF to the device master record and to the training records for personnel who will work under the modified process. A design change that requires FDA submission connects the DHF to the regulatory affairs function. In a standalone design control tool, these connections exist only through manual cross-reference or external document links. In eLeaP’s integrated QMS, they are system-record relationships.

CAPA-Driven Design Changes

When a CAPA investigation identifies a design-related root cause — a complaint about a device performance characteristic that was not adequately addressed in the original design validation, a nonconformance revealing that a design tolerance is not achievable in production, a field safety report indicating a use environment condition that the original user needs analysis did not capture — the corrective action requires a design change. In eLeaP, the design change record is initiated from within the CAPA record. The CAPA record links to the design change as its corrective action. The design change record links back to the CAPA as its originating quality event. An auditor reviewing either record can navigate to the other without leaving the quality system.

Design Changes Affecting Production Methods and Training

A design change that modifies a device component, a manufacturing process parameter, or a device labeling requirement affects both the DHF and the DMR, and requires retraining for personnel whose work activities are affected. In eLeaP, the design change control record identifies the DMR documents requiring revision as part of the change impact assessment. Those documents route through the document revision workflow. When the revised documents reach effective status, the integrated LMS generates retraining assignments for every role assigned to those documents. The design change cannot be closed until the DMR revisions are documented, the revised documents are effective, and the required training completions are confirmed. The training gate that applies to all document revisions in eLeaP applies equally to design-change-driven document revisions.

Design Changes Requiring FDA Submission Assessment

Some post-market design changes to cleared or approved medical devices require FDA submission before implementation: a new 510(k) for changes that could significantly affect safety or effectiveness, a PMA supplement for changes to approved devices, or a Special 510(k) for certain changes to the device’s design specifications, components, materials, or manufacturing processes. The design change control assessment must include a regulatory submission impact determination. In eLeaP, the design change impact assessment includes a regulatory submission field that routes to the regulatory affairs function when a submission assessment is required. The regulatory affairs determination and the submission status — pending, submitted, cleared, or not required — are tracked within the design change record. A design change that requires prior submission cannot advance to implementation sign-off until the submission status is confirmed.

Evaluating FDA Design Controls Software: Five Questions Beyond the Design Phase

Design control software evaluations that focus only on the development phase miss the ongoing lifecycle obligations under the QMSR and ISO 13485 Section 7.3. The five evaluative questions below test the full scope of design control software capability, including post-market design change management. Each question identifies a structural difference between document-management platforms and integrated quality management systems.

Question 1: Does the DHF Exist as a Navigable Record Network?

Does the DHF exist as a navigable record network where design inputs, outputs, verification, validation, and design reviews are linked as system records — or as a document folder where traceability depends on document naming conventions and manual cross-references? A document-folder DHF can satisfy a request for documents. It cannot satisfy a request to trace the relationship between a specific design input and the verification test that confirmed its corresponding output. A record-network DHF answers that request with a direct navigation, not a search.

Question 2: Is the Traceability Matrix a Live View or a Maintained Spreadsheet?

Is the traceability matrix a live view of the DHF record relationships that always reflects the current state of the design — or a manually maintained document that must be updated each time a design change is made? A manually maintained traceability matrix is accurate at the moment it is updated. Between updates, it is outdated. A system-generated traceability matrix is accurate at all times because it queries the current record relationships rather than reading from a static document.

Question 3: Does the Design Change Record Include a V&V Impact Assessment?

When a design change is initiated, does the change control record include a verification and validation impact assessment that identifies which prior V&V activities require repetition — and does the system prevent change closure until all required re-verification or re-validation is completed? A design change that bypasses V&V impact assessment is an open compliance risk. The design change control workflow must enforce the assessment and gate change closure on confirmed V&V completion where required.

Question 4: Can Design Changes Be Initiated from Within the CAPA Record?

When a CAPA identifies a design-related root cause, can the design change be initiated from within the CAPA record with the records bidirectionally linked — so that an auditor reviewing either record can navigate to the other without leaving the quality system? A design change initiated outside the CAPA system and cross-referenced only by document number creates a traceability gap. The bidirectional system-record link between the CAPA and the design change is the audit-ready connection.

Question 5: Does the System Gate Design Change Closure on Confirmed Training Completion?

When a design change affects production personnel training, does the system automatically generate training assignments for affected roles when the revised documents become effective — and gate design change closure on confirmed training completion? A design change that modifies a work instruction or manufacturing procedure is not complete until the personnel working under that procedure have completed training on the revised version. The training gate enforces this requirement at the system level, not at the quality manager’s discretion.

eLeaP’s answers to all five questions are yes. The design controls demonstration covers the full DHF record network view, the live traceability matrix, a post-market design change initiated from a CAPA record, and the training gate on design-change-driven document revisions. Request a scoped FDA design controls demonstration at eleapsoftware.com.

Frequently Asked Questions: FDA Design Controls Software

What are FDA design controls and which manufacturers are required to comply?

FDA design controls are the documented procedures and records that regulated medical device manufacturers must maintain to ensure devices are designed to meet specified requirements and user needs. Under the QMSR (effective February 2, 2026), design control requirements apply to manufacturers of devices that are subject to design or design changes. The QMSR incorporates the design control framework from ISO 13485 Section 7.3 as its base standard. Manufacturers of Class I devices that are not exempt and all Class II and Class III device manufacturers are generally subject to design control requirements. Design controls apply from initial design planning through every post-market design change — they are a product lifecycle obligation, not a development-phase activity.

What is the Design History File (DHF) and what must it contain?

The Design History File is the record set that documents the design history of a finished device. The DHF must contain or reference the records that demonstrate the device design was developed in accordance with the approved design plan and applicable regulatory requirements. Required DHF content includes design plans, design input records, design output records, design review records, verification records, validation records, design transfer records, and design change records. The critical compliance requirement is not just that these records exist — it is that the traceability relationships between them are demonstrable. A DHF where the connection between a design input and its corresponding verification test cannot be traced does not fully satisfy the record requirement.

What is the difference between design verification and design validation?

Design verification confirms that design outputs meet design input requirements — it answers the question: did we build the design we specified? Design validation confirms that the finished device meets defined user needs and intended use under actual or simulated use conditions — it answers the question: did we specify the right design? Both activities are required, both must be documented separately, and both must be linked to the specific design inputs or user needs they address. A verification test that confirms output specifications are met does not substitute for validation testing that confirms the device performs as intended by users in the intended use environment.

Does FDA design control software need to integrate with CAPA and change control?

Yes — and the integration requirement is regulatory, not just operational. When a CAPA investigation identifies a design-related root cause, the corrective action is a design change. The regulatory record trail must show the connection: CAPA identifies root cause, CAPA initiates design change, design change links back to CAPA. That connection must exist as system records that an auditor can navigate, not as document cross-references that depend on correct manual linking. Similarly, design changes that affect production procedures must connect to the change control system, which in turn connects to training management to ensure affected personnel are retrained before the change takes effect.

What is a design change control assessment and when is it required?

A design change control assessment evaluates the impact of a proposed change to a cleared or approved device design. The assessment must determine: whether the change requires new or additional verification or validation before implementation; whether the change affects any design inputs, outputs, or user needs already addressed in the DHF; and whether the change requires FDA submission before implementation. The assessment is required for every design change regardless of perceived scope — a change that appears minor may affect safety or effectiveness in ways that require pre-implementation submission. The design change control workflow must enforce the assessment and prevent change implementation until all required determinations are documented.

What is a live traceability matrix and how does it differ from a manually maintained spreadsheet?

A live traceability matrix is a system-generated view of the current record relationships in the DHF — it queries the actual links between user needs, design inputs, design outputs, verification tests, and validation studies at the time it is generated. A manually maintained traceability matrix is a document that reflects the DHF relationships as of the last time it was updated. The practical difference is audit readiness: a live traceability matrix is always current; a manually maintained spreadsheet may not reflect the current state of the DHF if design changes have been made since the last update. For Notified Body audits and FDA inspections, a live traceability matrix is a demonstrable advantage.

How do post-market design changes differ from pre-clearance design changes?

Post-market design changes are changes to a device that has already received FDA clearance or approval. They differ from pre-clearance design changes in three important ways. First, they require a regulatory submission impact determination — some changes require FDA submission (new 510(k), PMA supplement, Special 510(k)) before implementation, and the design change record must document that determination. Second, they must connect to the quality events that drove them: a post-market design change triggered by a CAPA or complaint must be traceable to its originating quality event. Third, they often require immediate connection to production: a post-market design change that modifies a manufacturing process must route to change control, DMR revision, and training completion before the change can be closed.

What is the training gate mechanism and why does it apply to design-change-driven document revisions?

The training gate mechanism in eLeaP prevents the closure of a document revision — and any associated quality event such as a design change — until all required training completions are confirmed for affected personnel roles. When a design change modifies a device component specification, a manufacturing procedure, or a labeling requirement, the revised documents become the new effective standard for production personnel. Training on the revised documents must be completed and recorded before the design change can be closed. The training gate enforces this requirement at the system level: when a revised document reaches effective status, the integrated LMS generates training assignments for every role associated with that document, and the design change record cannot advance to closed status until those assignments are confirmed complete.

About eLeaP QMS

eLeaP is a quality management and learning management platform built by Telania, LLC, founded in 2002. The platform is designed for regulated-industry manufacturers — pharmaceutical, medical device, biotech, CDMO/CRO, aerospace, food and beverage, and cannabis manufacturing — who require an integrated QMS and LMS in a single system. The core differentiator is native QMS+LMS integration: CAPA-triggered training assignments, document-revision-triggered training enrollment, and the training gate mechanism that gates record closure on confirmed training completion. For medical device manufacturers, eLeaP supports design controls, DHF management, traceability matrix maintenance, post-market design change management, and the full QMS suite connecting design to production to CAPA to training — without requiring a separate LMS vendor or manual cross-system integration.

Related resources:

• Medical Device QMS Software — production-phase quality system connecting DHF to production records
• ISO 13485 Software — Section 7.3 design and development clause map
• Change Control Software — post-market design change control workflow
• Medical Device Quality Management Software