Fiveable

🦾Biomedical Engineering I Unit 9 Review

QR code for Biomedical Engineering I practice questions

9.1 Design Process and Requirements Analysis

9.1 Design Process and Requirements Analysis

Written by the Fiveable Content Team • Last updated August 2025
Written by the Fiveable Content Team • Last updated August 2025
🦾Biomedical Engineering I
Unit & Topic Study Guides

Medical Device Design Process

Key Stages and Activities

Medical device design follows a structured, stage-gate process that moves from an initial idea all the way to a product on the market. Each stage builds on the previous one, and a device typically can't advance until it meets specific criteria at each gate.

  1. Ideation — Generating potential solutions to an identified clinical need through brainstorming, literature review, and market research. The goal here is breadth: explore many possible approaches before narrowing down.
  2. Concept development — Refining selected ideas into detailed designs that account for functionality, usability, manufacturability, and cost-effectiveness.
  3. Prototyping — Building physical or virtual models to test design assumptions, gather user feedback, and identify problems early (when they're cheapest to fix).
  4. Testing — Evaluating the device's safety, efficacy, and performance through bench testing, animal studies, and eventually human clinical trials.
  5. Regulatory approval — Demonstrating compliance with standards set by regulatory bodies like the FDA (in the U.S.) or notified bodies that grant CE marking (in the EU).
  6. Commercialization — Scaling up manufacturing, establishing supply chains, marketing the device, and conducting post-market surveillance to monitor real-world safety and effectiveness.

Lifecycle Considerations and Multidisciplinary Collaboration

The design process should account for the device's entire lifecycle: manufacturing, distribution, clinical use, maintenance, and eventual disposal or decommissioning. Decisions made early in design (like material selection) ripple forward into all of these stages.

This is why medical device teams are multidisciplinary. Engineers, clinicians, human factors specialists, and regulatory experts each bring perspectives that catch problems the others might miss. A clinician might flag a workflow issue an engineer wouldn't anticipate; a regulatory expert might identify a classification question that reshapes the design strategy.

Two principles run through every stage:

  • Human factors and ergonomics — Designing the device to minimize user errors, reduce cognitive and physical demands, and improve user satisfaction. For example, if nurses will use the device during a 12-hour shift, button placement and screen readability under fatigue matter enormously.
  • Risk management — Systematically identifying and mitigating potential hazards and failure modes throughout the design process, not just at the testing stage. Standards like ISO 14971 formalize this practice.

User Needs in Design

User Needs Analysis and Data Collection

Before you can design a device, you need to deeply understand who will use it and what they actually need. The intended users might be patients, surgeons, nurses, caregivers, or technicians, and each group has different priorities.

Methods for collecting user needs data include:

  • Interviews — One-on-one discussions that provide in-depth insight into user experiences, frustrations, and expectations
  • Focus groups — Moderated group discussions that surface a range of perspectives and reveal points of agreement or disagreement among users
  • Surveys — Structured questionnaires that gather quantitative and qualitative data from a larger sample, useful for identifying trends
  • Ethnographic studies — Observing and documenting user behaviors in their natural context (e.g., watching how a nurse actually handles an infusion pump during a shift, not just how the manual says to)
  • Observational research — Studying users in clinical settings to understand workflows, task sequences, and environmental constraints

Not all user needs carry equal weight. Prioritize them based on importance (how critical is this to the device's core function?), frequency (how often does this need arise?), and impact (what happens if this need goes unmet?).

Translating User Needs into Design Requirements

User needs are often expressed in qualitative, subjective language ("I need it to be easy to clean"). Design requirements translate those needs into specific, measurable, and testable criteria. For example, "easy to clean" might become: "Device surfaces shall be fully decontaminated using standard hospital wipes within 60 seconds, with no crevices smaller than 2 mm."

Requirements should cover:

  • Functional performance — What the device does, its features, and its capabilities
  • Usability — How easy it is to learn, operate, and navigate for the intended user population
  • Safety — Identified risks and the design controls that mitigate them
  • Reliability — Expected performance and durability over the device's intended service life (e.g., a pacemaker battery lasting 8–12 years)
  • Compatibility — Integration and interoperability with other systems (electronic health records, hospital networks, complementary devices)
  • Regulatory compliance — Applicable standards and regulations the device must satisfy

Translating needs into requirements takes close collaboration between the design team, clinical subject matter experts, and user representatives. Getting this wrong means you might build a device that meets its specs on paper but fails in practice. These requirements then guide every downstream activity: concept generation, prototyping, verification, and validation.

Systems Thinking for Design Integration

Holistic Approach to Medical Device Design

Systems thinking treats the medical device not as an isolated product but as one component in a larger ecosystem of people, processes, and environments. A beautifully engineered device that doesn't fit into existing clinical workflows will fail just as surely as one with a technical flaw.

Applying systems thinking means understanding the device's context of use:

  • Clinical workflow — How does the device fit into existing procedures? Does it replace a step, add a step, or change the sequence? If a device requires a nurse to stop and recalibrate mid-procedure, that's a workflow disruption you need to design around.
  • User characteristics — The physical abilities, cognitive load, training level, and emotional state of intended users. A device used in an emergency department faces very different user conditions than one used in a scheduled outpatient visit.
  • Environmental factors — The physical setting (operating room vs. patient's home vs. ambulance), lighting, noise level, available space, and organizational culture all shape how the device will actually be used.

This holistic view extends across the full lifecycle. How will the device be sterilized between uses? How will it be shipped without damage? What happens when it reaches end-of-life?

Balancing and Optimizing Design Considerations

Real-world design involves tradeoffs between competing requirements:

  • Functionality vs. Cost — Adding features improves capability but raises price
  • Usability vs. Safety — Making a device easier to operate might mean fewer safety interlocks, and vice versa
  • Manufacturability vs. Performance — The ideal material for performance might be difficult or expensive to manufacture at scale

There's no formula that resolves these tradeoffs automatically. The multidisciplinary team works together to find the best balance for the specific clinical context and target market. Human factors principles help ensure that wherever compromises are made, the user's ability to operate the device safely and effectively is protected.

Design Concept Evaluation

Assessing Feasibility, Safety, and Efficacy

Once you have multiple design concepts, you need a rigorous way to select the most promising one(s) to develop further. Evaluation focuses on three dimensions:

Feasibility considers whether the concept can realistically become a product:

  • Manufacturability — Can it be produced reliably with available technologies?
  • Scalability — Can production ramp up to meet demand while maintaining quality?
  • Cost-effectiveness — Does the expected cost structure support a viable price point for the target market?
  • Regulatory pathway — What classification does the device fall under (e.g., FDA Class I, II, or III), and what's the expected approval timeline and burden of evidence?

Safety evaluation identifies and mitigates potential hazards:

  • Mechanical hazards (device failure, breakage, unintended movement)
  • Electrical hazards (shock, fire, insulation failure)
  • Biological hazards (infection, contamination, adverse tissue reactions)
  • Chemical hazards (toxicity, biocompatibility of materials)
  • Use-related risks (user errors from misinterpreting outputs, incorrect setup, or improper maintenance)
  • Foreseeable misuse scenarios (intentional or unintentional misuse, with safeguards designed to prevent or limit harm)

Efficacy assessment determines whether the device can achieve its intended clinical purpose:

  • Preclinical studies — In vitro or in vivo experiments that establish proof-of-concept
  • Bench testing — Evaluating technical performance, reliability, and durability under controlled conditions
  • Early-stage clinical evaluations — Small-scale human studies assessing safety, feasibility, and preliminary effectiveness in the target population

Structured Evaluation and Iterative Refinement

Design concepts should be compared using structured tools rather than gut feeling:

  • Decision matrix — Lists evaluation criteria along one axis and design concepts along the other, allowing side-by-side comparison against each criterion
  • Weighted scoring system — Assigns numerical scores for each criterion and multiplies by a weight reflecting that criterion's relative importance. The concept with the highest total weighted score is typically the strongest candidate, though the team should examine the breakdown, not just the final number.

User feedback should be incorporated at this stage, not just at the end. Testing low-fidelity prototypes or mockups with actual users can reveal misalignments between the design concept and real user needs before significant resources are committed.

Refinement is iterative. Based on evaluation results, the team may:

  1. Modify features, materials, or components to address identified weaknesses
  2. Run additional testing or simulations to validate that changes actually improve performance and safety
  3. Gather further user input to confirm the refined concept better meets their needs

This cycle of evaluate-refine-retest continues until the concept is strong enough to justify moving into more resource-intensive development stages. The earlier you catch and fix problems, the less expensive they are to resolve.