Design Inputs to Design Outputs: A Discovery Phase Checklist

What This Template Includes

A structured checklist covering the discovery phase of medical device development — the work that happens between "we have an idea" and "design inputs are baselined." The checklist is organized into six sections matching ISO 13485 §7.3 and FDA 21 CFR 820.30 design control requirements:

1. User needs definition
2. Intended use and indication scoping
3. Regulatory strategy and classification
4. Initial risk analysis
5. Design input development
6. Design input baseline and traceability matrix setup

The template is designed for use by R&D, regulatory affairs, and quality teams in early-stage discovery — before formal design transfer, before V&V planning, often before product engineering staffing.

Why the Discovery Phase Matters

Most design control failures discovered in audits trace back to the discovery phase. Specifically:

• User needs that were assumed but never documented, surfacing as gaps in V&V coverage.
• Intended use phrasing that was set casually early on, then realized to drive Class III classification in some markets.
• Risk analysis that started after design inputs were baselined, instead of informing the inputs.
• Predicate/equivalence assumptions made during discovery that don't survive regulatory scrutiny.

Discovery is the cheap phase to fix mistakes. A user need correction in discovery is a paragraph rewrite. The same correction six months into development is a re-architecture.

Who This Is For

• R&D teams beginning a new medical device project
• Regulatory affairs teams supporting discovery-stage work
• Companies pivoting an existing product to a new indication or new market
• Software-led teams who have built MVP product and now need to formalize design controls retrospectively

Section 1: User Needs Definition

The user needs document captures the unmet clinical need the device addresses, in language that does not yet make engineering decisions.

Checklist items:

• Primary user identified (physician, nurse, technologist, patient, caregiver)
• User profile documented (training, experience level, environmental context)
• Clinical setting documented (hospital, clinic, home, EMS)
• Workflow integration scoped (where in the clinical workflow does this device fit?)
• Unmet need articulated (what is currently not being done well?)
• User research evidence cited (interviews, observation, literature)
• User goal stated in user language (not engineering language)
• Use environment characterized (lighting, sterility, time pressure, distractions)
• Use frequency and duration estimated
• Failure consequences from user perspective scoped

Common mistakes:

• Writing user needs in engineering language ("the device shall measure with ±2% accuracy" — this is a design input, not a user need).
• Single-user-type assumption when multi-user reality applies (a surgical device used by surgeon, scrub tech, and circulating nurse has three user types).
• Missing the supporting user (the technician who calibrates, the IT admin who configures).

Section 2: Intended Use and Indication Scoping

The intended use statement is the most consequential single sentence in the regulatory file. It drives classification, predicate/equivalence, labeling, and indication scope.

Checklist items:

• Intended use draft in compliant phrasing (verb + device + patient population + condition)
• Indications for use distinguished from intended use (FDA and EU/Korea distinguish; many design teams conflate)
• Patient population scoped (age range, disease state, comorbidities)
• Body part / target tissue defined
• Duration of use defined (single-use, short-term, long-term)
• Anatomical access defined (non-invasive, invasive, implantable)
• Sterility requirements scoped
• Multi-region intended use phrasing compared (FDA, EU, Korea variations)
• Contraindications drafted
• Off-label use anticipated and documented (not necessarily prohibited; just acknowledged)

Common mistakes:

• Maximalist intended use ("for the diagnosis and treatment of cardiovascular disease") that creates classification problems.
• Single-region phrasing that creates re-translation cost when entering other markets.
• Failing to scope the patient population, leading to ambiguous clinical evidence requirements later.

Section 3: Regulatory Strategy and Classification

The classification opinion drives the entire development plan.

Checklist items:

• FDA classification (Class I, II, or III) with rule citation
• EU MDR classification with rule citation (Rules 1–22)
• MFDS classification with item code
• PMDA classification (if Japan in scope)
• NMPA classification (if China in scope)
• Predicate or equivalence devices identified per region
• Submission pathway identified per region (510(k), De Novo, PMA, CE technical file, MFDS notification/approval)
• Clinical evidence need estimated per region
• Cybersecurity scope (does the device have any connectivity? if yes, plan for cybersecurity submission)
• Special device categories considered (combination product, custom device, accessory)

Common mistakes:

• Single-region classification analysis assumed to transfer. Cross-region classification analysis is foundational.
• Predicate device selected casually. The predicate drives the FDA file structure; a weak predicate creates rework.
• Cybersecurity scope underestimated for connected devices. Any networking pushes the device into the cybersecurity submission framework.

Section 4: Initial Risk Analysis

Risk analysis begins before design inputs are baselined and continues throughout development.

Checklist items:

• Hazard identification methodology selected (ISO 14971 §5, possibly extended with STAMP/STPA or FMEA)
• Reasonably foreseeable hazards listed (user error, software failure, hardware failure, environmental, biological)
• Hazardous situations mapped from hazards
• Initial risk estimation (severity × probability) for each hazardous situation
• Risk acceptability criteria documented
• Initial risk control measures proposed
• Residual risk for each hazardous situation estimated
• Risk-control-to-design-input linkages drafted
• Risk management plan documented
• Risk management file structure set up

Common mistakes:

• Treating risk analysis as a post-design exercise. ISO 14971 requires risk analysis to inform design inputs, not be done after the fact.
• Skipping foreseeable misuse. User error is one of the most common harm sources; analyzing only "correct use" misses much of the real risk profile.
• Software risk analysis as separate from device risk analysis. Software is part of the device; software hazards integrate into the device risk file.

Section 5: Design Input Development

Design inputs are the engineering-language requirements that flow from user needs, intended use, and risk analysis.

Checklist items:

• Each design input is verifiable (measurable, testable)
• Each design input traces to a user need, intended use element, risk control, or regulatory requirement
• Functional inputs distinguished from non-functional inputs
• Performance specifications quantified (not "fast," but "≤2 seconds for X operation")
• Environmental inputs scoped (temperature, humidity, EMI, mechanical shock, transport conditions)
• Regulatory inputs captured (applicable standards, harmonized standards)
• Compatibility inputs (compatible accessories, compatible patient interfaces, compatible electrical environments)
• Cybersecurity inputs (for connected devices) — authentication, encryption, vulnerability management, end-of-support window
• Service and maintenance inputs (cleanability, calibration, software update mechanism)
• Labeling inputs (UDI requirements, multilingual labeling, accessibility)

Common mistakes:

• Unverifiable inputs ("user-friendly" is not testable; "completes Task X in under 30 seconds with no errors per usability study" is).
• Missing non-functional inputs (cybersecurity, service, environmental) leading to late-stage redesign.
• No traceability — inputs written in isolation rather than traced to user needs and risks.

Section 6: Baseline and Traceability Matrix

The baseline is the formal handoff from discovery to development. After baseline, changes go through change control.

Checklist items:

• Design inputs reviewed and approved
• Traceability matrix populated linking user needs ↔ intended use ↔ risk controls ↔ design inputs
• Baseline version captured in PLM (or equivalent design history system)
• Change control procedure activated for any subsequent changes
• Development plan drafted (V&V, design transfer, validation, regulatory submission timing)
• Resource estimate prepared
• Risk management plan baselined
• Discovery phase formally closed (design review meeting, signatures, records)

Common mistakes:

• Baseline declared but change control not actually applied (changes continue informally).
• Traceability matrix built as a one-time deliverable rather than a living artifact.
• No design review meeting — the baseline is implicit rather than explicit, making later audits harder to defend.

Discovery Phase Output

At the end of discovery, the project has:

• User needs document (baselined)
• Intended use statement (baselined, multi-region phrasing reviewed)
• Regulatory strategy (classification, pathway, predicate/equivalence per region)
• Initial risk analysis (baselined, structured in ISO 14971 risk file)
• Design inputs (baselined, traceable)
• Traceability matrix (initial population)
• Development plan and resource estimate
• Risk management plan

This package is what enables a confident development phase. Without it, development carries hidden gaps that surface late.

Download

Download the full Discovery Phase Checklist PDF — includes editable Word/Excel companions for the traceability matrix and risk analysis worksheets.

Where Leanabl Plugs In

For teams wanting hands-on support through the discovery phase, Discovery & Design runs the work alongside R&D, producing the baselined design controls deliverables. Design output management for the rest of development is handled through Design Output. For multi-region regulatory strategy that anchors classification decisions, Regulatory Foundations sets the strategic framework.