Your DHF Is Not a Jira Board: Design Controls That Survive FDA Inspection

Executive Takeaway

• What changed: The QMSR (effective February 2, 2026) replaced 21 CFR 820.30 with ISO 13485:2016 Clause 7.3 by reference. Design control requirements are now tied to an international standard, but the substance is largely the same — inputs, outputs, reviews, verification, validation, transfer, and changes.
• Why it matters: Design control deficiencies are consistently among the top 5 FDA 483 observations. A Jira board is not a DHF. Email threads are not design reviews. Agile development is not exempt from design controls.
• What to do next: Map your existing development artifacts to design control phases. Identify gaps in design review documentation, V&V traceability, and design transfer records. Build a DHF index that an auditor can follow.

The Scenario Every Software Device Team Recognizes

A software medical device team has been shipping iterative releases for 18 months. Their clinical decision support tool processes patient data, generates risk scores, and integrates with hospital EHR systems. Development follows two-week sprints with daily standups, PR reviews, and quarterly roadmap planning. The design history file is a collection of Jira tickets organized by epic, Confluence pages documenting architecture decisions, and email threads capturing stakeholder feedback.

During a routine FDA inspection, the investigator opens the DHF and finds no controlled index, no formal design review records, and no traceability between design inputs and verification test cases. The 483 observation reads: "failure to maintain a complete design history file" and "design reviews not conducted or documented per established procedures." The VP of Engineering asks: "we have thousands of Jira tickets, 200 Confluence pages, and test coverage above 90% — what exactly do we need to fix?"

The quality team realizes the artifacts exist. The requirements are in Jira epics. The architecture is documented in Confluence. Test results live in the CI/CD pipeline. But the traceability is missing. Design reviews happened in standup meetings and PR approvals, but were never formally documented with attendees, agenda, decisions, and action items. The gap is not in the work — it is in the evidence trail.

What the Regulation Requires

Design controls are not optional for any class of medical device that requires design controls under FDA regulations (Class II and III devices, and Class I devices subject to design controls). The regulatory framework spans multiple standards and guidance documents.

21 CFR 820.30 (now [Reserved] under QMSR)

The former Quality System Regulation (QSR) Section 820.30 defined design control requirements for medical devices in the United States. As of February 2, 2026, the QMSR replaced the QSR and Section 820.30 is now [Reserved]. Design control requirements are incorporated by reference to ISO 13485:2016 Clause 7.3.

ISO 13485:2016 Clause 7.3 (Design and Development)

Clause 7.3 covers the full design lifecycle in ten sub-clauses: 7.3.1 (General), 7.3.2 (Design and development planning), 7.3.3 (Design and development inputs), 7.3.4 (Design and development outputs), 7.3.5 (Design and development review), 7.3.6 (Design and development verification), 7.3.7 (Design and development validation), 7.3.8 (Design and development transfer), 7.3.9 (Control of design and development changes), and 7.3.10 (Design and development files).

IEC 62304 — Software Lifecycle Processes

For software medical devices and software components of medical devices, IEC 62304:2006+A1:2015 defines software development lifecycle requirements. Software safety classification (Class A, B, or C) determines the rigor of documentation, verification, and testing requirements. IEC 62304 integrates with ISO 14971 for risk management throughout the software lifecycle.

Additional Guidance

FDA's 1997 guidance document "Design Controls" remains a foundational reference for understanding design control intent and practical implementation. The EU MDR 2017/745 Annex II defines technical documentation requirements for design and manufacturing information. Health Canada's CMDR (Canadian Medical Devices Regulations) also requires design controls aligned with ISO 13485.

Seven Common Failure Modes in Design Control Documentation

1. Treating Jira/Confluence as the DHF without a controlled index

Project management tools are artifacts, not the design history file. A DHF requires a controlled index that maps every design control phase to its corresponding document, revision, and approval status. A Jira board has no formal document control, no revision history with approval signatures, and no mechanism to demonstrate completeness to an auditor.

2. No documented design reviews

Standup meetings, Slack threads, and pull request approvals do not constitute design reviews under ISO 13485 Clause 7.3.5. A design review must be a formal, planned evaluation with documented attendees (including independent reviewers), a defined agenda covering design inputs and outputs, recorded decisions, identified problems, and tracked action items with responsible parties and completion dates.

3. Design inputs that are actually design outputs

A common confusion: mixing "the device shall monitor heart rate continuously" (design input — a requirement) with "the device uses a photoplethysmography sensor sampling at 100 Hz" (design output — a specification). Design inputs define what the device must do and under what conditions. Design outputs describe how the device achieves those requirements. Confusing the two creates circular traceability.

4. Verification without traceability to design inputs

Test cases exist, code coverage is high, but there is no documented mapping from individual design input requirements to specific verification test protocols and results. An auditor expects to pick any design input from the requirements specification and trace it forward to a verification test that confirms the output meets the input. Without a traceability matrix, this is impossible.

5. Validation performed only in-house

Design validation must confirm the device meets user needs and intended use under actual or simulated use conditions. Testing performed only by developers or internal QA staff in a lab environment does not satisfy this requirement. Validation must involve representative end-user populations (e.g., clinicians, nurses, patients) in environments that simulate real-world use conditions.

6. Design changes not routed through change control

Software teams deploy "hotfixes," "patches," and "minor updates" without formal design review or risk assessment. Every change to a released medical device — including software updates, UI modifications, algorithm adjustments, and configuration changes — must route through the design change control process per ISO 13485 Clause 7.3.9. Each change requires evaluation of its impact on existing risk controls and V&V results.

7. No design transfer documentation

Design transfer is the documented handoff of design outputs to production specifications. For software devices, this includes the CI/CD pipeline configuration, build environment specifications, release procedures, and deployment validation. Many software teams skip design transfer documentation entirely, assuming that "code in the repository" is sufficient. It is not.

Audit-Proof Design Control Checklist

Use this checklist to verify that your design history file contains the evidence artifacts that auditors expect to see.

The 10-Step Design Control Workflow

1. Create a Design and Development Plan. Define project phases, milestone reviews, deliverables for each phase, team roles and responsibilities, and references to applicable standards (ISO 13485, IEC 62304, ISO 14971).
2. Capture Design Inputs. Document user needs, intended use, applicable regulatory requirements, risk management inputs (from ISO 14971 hazard analysis), performance requirements, and compatibility requirements. Inputs must be verifiable.
3. Document Design Outputs. Record specifications, software architecture documents, interface definitions, labeling content, and packaging specifications. Each output must be traceable to one or more design inputs.
4. Build the Traceability Matrix. Every design input maps to at least one design output. Every design output maps to at least one verification test. Every verification test links to test results. This matrix is the backbone of your DHF.
5. Conduct Design Reviews at phase transitions. Schedule formal reviews at defined milestones. Document attendees (including at least one independent reviewer not directly responsible for the design), agenda items, review of design inputs vs. outputs, decisions made, problems identified, and action items with owners and due dates.
6. Execute Design Verification. Test design outputs against design input specifications. Verification answers the question: "Did we build it right?" Protocols, acceptance criteria, and results must be documented and traced to specific design inputs.
7. Execute Design Validation. Test the finished device under actual or simulated use conditions with representative users. Validation answers the question: "Did we build the right thing?" Include usability studies, clinical evaluations, and user acceptance testing as appropriate.
8. Perform risk management activities throughout. Integrate ISO 14971 risk management at each design phase. Risk management outputs (identified hazards, risk controls, residual risk evaluation) feed back into design inputs. Update the risk management file whenever design changes affect risk controls.
9. Complete Design Transfer. Document the transfer of design outputs to production specifications. For software: release build procedures, deployment pipeline configuration, environment specifications, and production validation. Verify that production output matches design output.
10. Maintain the DHF as a living document. All design changes after initial release must go through change control per ISO 13485 Clause 7.3.9. Each change requires impact assessment, risk evaluation, appropriate V&V, and updated traceability.

Do / Don't Quick Reference

Practical Example: SaMD with OTA Updates

Consider a Software as a Medical Device (SaMD) clinical decision support tool that processes patient vitals data and generates risk stratification scores. The development team releases updates via over-the-air (OTA) deployment to hospital servers. Here is how design controls apply at each phase.

Design Inputs live in Jira epics, but each epic is formally signed off by the product owner and systems engineer. The sign-off is exported to PDF and stored in the DHF with a controlled document number. Requirements cover intended use, user needs from clinician interviews, regulatory requirements from IEC 62304 and applicable FDA guidance, and risk management inputs from the ISO 14971 hazard analysis.

Design Reviews are conducted as dedicated review meetings — separate from sprint retrospectives or PR approvals. The review meeting has a defined agenda, invitees include an independent reviewer from the quality team who was not involved in the design, and meeting minutes document decisions, open issues, and action items. PR approvals are supplementary evidence, not the design review itself.

Design Verification uses an automated test suite where each test case is mapped to a specific design input requirement in the traceability matrix. Test results from the CI/CD pipeline are captured as controlled test reports. Coverage is measured against design inputs, not just code lines.

Design Validation involves a usability study with board-certified clinicians at two hospital sites using the device in simulated clinical workflows. The validation protocol is approved before execution, and results are documented in a formal validation report.

Design Transfer treats the CI/CD pipeline as the controlled manufacturing process. Pipeline configuration, build environment specifications, deployment scripts, and release validation checklists are documented as design transfer records. The production build is verified to match the validated design output.

Design Changes for each OTA update route through the change control process. The change request includes a description of the change, impact assessment on existing design inputs and outputs, risk assessment per ISO 14971, determination of required V&V, and approval by the change control board before deployment.

SaMD Design Control Artifact Map

Ask Our Regulatory Intelligence Tool

Use the TrueMedDevice deep research tool to investigate design control requirements, enforcement patterns, and regulatory expectations for your device type.

Example queries:

• "What FDA 483 observations cite design control deficiencies for software medical devices?"
• "Compare ISO 13485 Clause 7.3 with former 21 CFR 820.30 design control requirements"
• "Show me enforcement actions related to design history file gaps"

Ask a Design Controls Question →

Design Controls Don't End at Market Release

Post-market surveillance data feeds directly back into design controls. Complaint trends validate or challenge design verification assumptions. Competitor recalls reveal design pitfalls to avoid in your next-generation device. Field safety corrective actions from similar devices inform design input revisions.

TrueMedDevice monitors 618,000+ FDA and Health Canada records to help you close the loop between post-market data and design inputs.

• Monitor competitor 510(k) clearances and recalls relevant to your device design — identify design approaches that succeeded and those that led to field problems.
• Build traceability from field complaints back to design verification assumptions — when complaint trends emerge, trace them to the design inputs and verification tests that should have caught the issue.
• Generate audit-ready evidence packs showing the post-market feedback loop to design — demonstrate to auditors that your design controls are informed by real-world performance data.

Search Regulatory Evidence →    Take the Free PMS Gap Assessment

Conclusion

Design controls are not bureaucracy — they are the evidence trail that your device was designed systematically, verified against specifications, and validated for its intended use. The QMSR alignment with ISO 13485 does not change the substance of design control requirements — it standardizes the language and harmonizes the framework with international expectations.

Teams that map their existing development artifacts to design control phases close the gap between how they actually work and what auditors expect to see. The work is already happening. The artifacts often already exist. What is typically missing is the controlled index, the formal review documentation, and the traceability that connects inputs to outputs to verification evidence.

Start with the checklist above. Identify which artifacts you have today, where they live, and what gaps remain. Build your DHF index. Schedule your first formal design review. The cost of doing this proactively is a fraction of the cost of a 483 observation, a warning letter, or a product recall.

Use TrueMedDevice to search 618,000+ regulatory records for enforcement patterns, competitor design control findings, and post-market data relevant to your device type.