The first thing FDA inspectors examine is your Design History File.

They'll start with user needs. Trace to design inputs. Follow through design outputs. Verify against design verification. Confirm with design validation.

This chain must be complete, consistent, and documented. And it all starts with requirements.

Document-based requirements management cannot reliably support this chain. Modern medical device development demands better.

The Design Control Framework

21 CFR Part 820: Design Controls

FDA's Quality System Regulation requires:

Design Input: Requirements derived from user needs
Design Output: Design that meets design input
Design Verification: Confirmation output meets input
Design Validation: Confirmation device meets user needs

Each step requires documentation. Each step requires traceability to previous steps.

The Requirements Chain

User Needs
Design Input Requirements
Design Output
Design Verification (output meets input)
Design Validation (device meets user needs)

Every link in this chain is a requirement-based traceability relationship.

Where Requirements Live

User Needs: What clinical problem does the device solve?
Design Input: Engineering requirements derived from user needs
System Requirements: High-level system behavior
Subsystem Requirements: Hardware, software, mechanical specifications
Component Requirements: Detailed implementation specifications

Why Document-Based Requirements Fail

The Traceability Matrix Problem

A diligent team creates a traceability matrix linking:

User needs to design inputs
Design inputs to design outputs
Design outputs to verification activities

On the day it's created, it's accurate.

Six months later:

23 requirements changed
8 new requirements added
5 requirements deleted

The matrix reflects none of this. It's now a liability, not an asset.

The Version Control Problem

The design input requirement was in version 7 of the SRS. Or was it version 8? Someone edited version 7 after version 8 was released.

When inspectors ask for requirements evidence, which version do you provide?

The Impact Analysis Problem

"What's affected if we change the alarm threshold?"

In a document system, this question triggers a multi-day investigation. Engineers search documents, hope they find everything, document their search methodology.

In a modern tool, this is a database query returning in seconds.

Modern Medical Device Requirements Management

Single Source of Truth

Every requirement lives in one place. One version. Always current.

No more version conflicts. No more "which document has the latest?"

Native Traceability

Requirements link to:

Parent requirements (user need → design input)
Child requirements (system → subsystem → component)
Risk analysis (requirements analyzed for hazards)
Verification (tests that verify requirements)
Validation (clinical evidence supporting user needs)

These links are data, not text references. When a requirement changes, every linked item is flagged for review.

Automatic Impact Analysis

Change a design input and immediately see:

Affected design outputs
Affected verification activities
Risk analyses needing review
Validation implications

No searching. No hoping. Complete visibility.

Attribute Management

Requirements have attributes beyond text:

Status: Draft, Reviewed, Approved, Implemented, Verified
Type: User need, Design input, Software, Hardware
Owner: Responsible engineer
Verification Method: Test, Analysis, Inspection
Risk Association: Linked hazards

Filter and report on any combination. Find all unverified software requirements with one query.

IEC 62304: Software Requirements

Medical device software has specific requirements practices.

Software Safety Classification

Software requirements include safety classification:

Class A: No injury or damage possible
Class B: Non-serious injury possible
Class C: Death or serious injury possible

Classification drives verification rigor.

Software Requirements Specification

IEC 62304 requires:

Functional requirements
Input/output requirements
Interface requirements
Timing requirements
Safety requirements

Traceability Requirements

The standard requires traceability from:

System requirements to software requirements
Software requirements to software items
Software items to source code
Software requirements to tests

In document systems: This traceability exists in tables that nobody maintains.

In modern systems: This traceability is live data that maintains itself.

Integration with Risk Management

Requirements → Hazards

ISO 14971 requires identifying hazards associated with device functions. Those functions are defined by requirements.

Links should exist:

Function requirement → Associated hazards
Hazard → Contributing failure modes
Failure modes → Risk control requirements

Risk Control Requirements

When risk analysis identifies unacceptable risks, risk controls are required. These become requirements:

"Alarm shall sound within 30 seconds of detecting arrhythmia"
"Battery shall provide minimum 4 hours operation"
"Display contrast shall support visibility in dim lighting"

These derived safety requirements should trace back to the risk analysis that generated them.

Verification of Risk Controls

Risk control requirements need verification like any other requirement. But the verification must demonstrate the control actually reduces risk—not just that the device meets a specification.

Design Transfer Considerations

Manufacturing Requirements

Design transfer requires translating design requirements to manufacturing specifications:

Component specifications
Process parameters
Quality acceptance criteria
Test requirements

These trace back to design requirements. When design requirements change, manufacturing specifications need review.

Supplier Requirements

Many medical devices use purchased components. Supplier requirements should:

Flow down from device requirements
Be verified through supplier qualification
Link to incoming inspection criteria

The Design History File

What FDA Expects

The DHF contains:

Design and development planning
Design input documentation
Design output documentation
Design review records
Verification evidence
Validation evidence
Design transfer records

Requirements as Foundation

Requirements are the thread connecting all DHF elements:

Planning identifies requirements to be defined
Design input IS requirements
Design output implements requirements
Verification confirms requirements are met
Validation confirms user needs (top-level requirements) are satisfied

Modern DHF Generation

When requirements live in a database:

DHF reports generate automatically
Traceability exports on demand
Version history maintained automatically
Evidence links preserved

DHF compilation: Hours instead of weeks.

Multi-Site and Supplier Reality

Typical Structure

Medical device companies often involve:

Corporate design team
Regional design centers
Contract manufacturers
Component suppliers

Requirements Flow

Corporate defines user needs and system requirements
Design centers develop subsystem requirements
Suppliers receive component requirements
Contract manufacturers receive manufacturing requirements

Collaboration in Modern Systems

When requirements live in the cloud:

Everyone sees current requirements
Changes propagate to affected parties
Status visible across organizations
Version conflicts eliminated

Making the Transition

Don't Start with Migration

The worst approach: trying to migrate your entire legacy document system.

Better approach: Start with new product development.

No legacy baggage
Team learns new way together
Success creates internal champions

Import What You Need

For legacy products:

Import current baseline requirements
Establish traceability going forward
Backfill traceability as needed for audits

NirmIQ's AI-powered import handles medical device document formats—even decades-old Word specs with tracked changes.

Measure Improvement

Track before and after:

Time for impact analysis
Traceability accuracy
Inspector findings on requirements
Design change cycle time

The Payoff

Regulatory Confidence

Always ready for inspection
Complete traceability on demand
Fewer 483 findings

Development Efficiency

Faster impact analysis
Shorter design review cycles
Clearer handoffs between phases

Quality Improvement

Catch issues earlier
Fewer downstream changes
Better product outcomes

Requirements That Support Patient Safety

Medical devices save lives. But only when requirements are right—captured completely, traced thoroughly, verified completely, validated against actual patient needs.

NirmIQ delivers medical device requirements management:

Design control alignment
IEC 62304 software support
Risk management integration
AI-powered import
Complete traceability

Your requirements define what you're building to protect patients.

Make sure they're managed accordingly.

Medical Device Requirements: From User Needs to Design History File