Case Study: Seeding Risk & HFE During the Concept Phase (MedTech)

Same medical device, same cross-functional team, two different concept development methods. One produced a concept direction, a triangular risk, and five open questions handed to engineering. The other produced Kano rated design inputs, ranked failure modes, and a mapped user process before engineering opened a file and before risk management opened a hazard log.

If you work in medical devices and you live inside HFE plans and risk management files, that second output is going to look familiar. That’s what this video is about. Here’s how this case study played out.

The product and business is completely fictional for this use case, but we’re naming it Clear Air.

It’s a portable oxygen concentrator for home use by COPD patients.

The [00:01:00] primary user is Margaret. She’s 68, COPD stage three, managing oxygen dependency while staying mobile in her daily life. There’s also a second user in the story: Dr. Chen, Margaret’s prescribing physician who defines the clinical requirements the device has to meet.

This is a realistic use case because of four things.

First, it’s a medical device, class II, 510K regulatory pathway. Human factors and risk management aren’t optional features. They’re required analyses, which makes this a meaningful test of whether concept development can produce outputs those teams can actually use.

Second, multiple users with different requirements. Margaret lives with a device. Dr. Chen specifies what it has to do clinically. Those aren’t the same requirements and concept development has to address [00:02:00] both.

Third. There’s three performance requirements that genuinely conflict. Oxygen purity at or above a certain level and flow rate: that’s the clinical floor. The total system weight: that’s Margaret’s mobility threshold. And noise levels are for a dignified use in public and uninterrupted sleep. You cannot fully optimize all three simultaneously; every design decision moves the needle on at least two of them.

And fourth, a BOM gap going in: financial target of about $1000 against an engineering estimate of about $1200 to $1500. This is a shortfall before a single design decision is locked.

Here’s the experiment. Two complete concept development trials. Same product brief, [00:03:00] same team composition. Trial one used a traditional method, which are five structured rounds from project kickoff through risk and feasibility. Trial two used the _Pierce the Design Fog _method with the ADEPT team framework. Three sessions, each working a different lens: benefit- impact, symptom- impact, and use process.

The team was AI powered cross-functional agents. They covered six functions, engineering, manufacturing, quality marketing, sales, and customer success. If you’ve ever worked on a cross-functional team, the sessions look like a team chat. Each agent posting from their functional perspective, responding to each other, debating.

Engineering flags a thermal constraint quality follows with a severity rating. Customer success pushes back with what Margaret actually does in that moment. It’s [00:04:00] not a monologue, it’s a working session. The AI made it possible to run both complete trials quickly and compare outputs directly. That’s the mechanism and the story is what came out of it.

Our hypothesis is that Pierce the Design Fog would produce more work and that was expected. But the question was whether it would produce better design inputs and for this audience, whether those outputs would be usable by the HFE team and the risk management team downstream, or whether those teams would still be starting from scratch.

Let’s start with what the traditional method produced. Let me give the traditional method a fair read. It’s not bad work.

The team reviewed the product, brief flagged initial concerns by discipline, and explored three concept directions. The hybrid system was rejected, too many [00:05:00] reliability and cost trade-offs. The wearable micro pump concept was left unresolved. And the integrated continuous flow architecture was the leading direction because it was most reliable and most manufacturable.

The team named the core tension and gave it a label: a triangular risk. Weight, noise, and thermal management conflict with each other. Address one, and you create a trade off on the other. That’s the team’s discovery. They didn’t just list requirements. They identified the dynamic between them and named it.

What engineering received was one concept direction, design specifications at the project level, the triangular risk, and five open questions. Is the 43 decibels achievable without adding mass? What runtime does Margaret actually need? What’s the minimum compressor footprint that maintains purity at a certain flow? How do [00:06:00] we close the BOM gap? What’s the regulatory pathway?

The team did real work. The concept, direction chosen, risk surfaced, BOM gap named. But the design inputs are system level, not traced to Margaret’s experience. There’s no prioritization of her experiences, no failure mode ranking, and those five questions were handed to engineering without owners assigned.

Engineering can build from this, but they’re carrying ambiguity that wasn’t resolved in concept development.

Now here’s what changed when the team ran the methods in Pierce the Design Fog , including the ADEPT team framework. First, they performed a Kano analysis. The team worked through what Margaret and Dr. Chen actually experienced and rated each benefit.

For clinical [00:07:00] reliability, consistent oxygen delivery at the prescribed flow rate: that was rated a must have. This one is tied to Dr. Chen. If the device fails to deliver at the prescribed rate, it’s not Margaret’s preference that’s at risk. It’s Dr. Chen’s patient. That’s a safety critical function, and the Kano rating reflects it.

Weight and battery duration are performance benefits for Margaret and the team treated them as paired. A heavier battery might extend runtime, but it also pushes against. Heavier battery might extend runtime, but it also pushes against the weight threshold. Every decision about one moves the other linear trade off and quantifiable.

Social flow is the ability to use the device in public without drawing attention. And this is rated as attractive. That’s the differentiator. And the team didn’t limit [00:08:00] it to acoustic performance. It’s the sound, yes, but it’s also the setup sequence in a restaurant. The carry bag interaction, the visual profile in a social setting.

A device that’s clinically sound, but socially stigmatizing will stay in the closet, which defeats the clinical goal.

These three Kano categories map directly back to the green light packet. Oxygen purity maps must -have. Weight maps to performance. Acoustic performance is part of social flow. A social flow is broader than the 43 decibel spec. The team added context the spec alone didn’t carry.

Next, they performed a symptom- impact analysis. Before starting, they aligned on a severity scale for this product one through six, six being catastrophic. That decision shapes every rating that follows.

The frame for the [00:09:00] analysis is what goes wrong. Failure modes that are rooted in Margaret’s use process rated by severity. And the design inputs aren’t just “prevent this from happening”. They address what drives the failure to occur or what makes the consequence worse when it does.

Number one: user interface ambiguity leading to an incorrect flow rate setting. Margaret believes she’s receiving therapy, but she isn’t. That’s a high severity. The design inputs are related to physician locked presets with a multiple step override user interface. The flow rate spec came from the greenlight packet. The failure mode is new- how a user can interact with a device in a way that defeats the spec.

Number two: mechanical bypass of safety interlocks. The user circumvents the lock which can lead to undetected hypoxemia. [00:10:00] This is critical. The kind of design inputs related to this are a hardware interlock physically separate from the user interface controls. Our green light packet said safety thresholds had to be defined. Pierce the Design Fog decomposed how a user breaks them in the field and what that costs clinically.

Number three: hypoxemia detection latency. There’s a drop before the alarm triggers during a flow interruption, and this is high. The related design inputs are a defined alarm threshold calibration. That’s a new discovery that’s not in the green light packet.

Four and five relate to battery failure under load and noise disturbance during social use. Medium and low- medium severity with specific design inputs for each. The battery one [00:11:00] connects back to the weight and runtime trade off surfaced on the Kano analysis. The outputs reinforce each other.

The third analysis the team performed was they mapped Margaret’s use process. They rated each step by criticality and identified what the use process reveals about the device design. They identified eight steps from first power on through physical setup: donning the cannula, verifying oxygen flow, active mobile use, transitioning the device to the carry bag all the way to device ready state.

The critical to quality analysis produced some of the biggest findings of the session. Two high findings and one medium, and all three relate to the concentrator’s interface with the bag. That’s a thread running through the use process that you wouldn’t see from the product spec alone.

The first high one is a transition and latch [00:12:00] risk. Step six is Margaret moving the device into the carry bag. The mechanical reliability of that attachment- how it seats, how it locks, how it releases- is rated high. It’s the moment in the use process where the physical interface between device and system is most exposed.

The second high- rated item was thermal dissipation. Heat generated during continuous flow operation has to go somewhere, and where it goes affects the back surface of the device and how it interfaces with the bag. That’s an architectural constraint, not just a thermal spec. It shapes the physical design of the device exterior.

The medium finding was a critical silent flow. In step four, flow verification, Margaret needs confirmation that oxygen is flowing. In a dark bedroom, she can’t rely on the visual user interface. Startup confirmation needs to be [00:13:00] non-auditory, or provide redundant feedback. That’s a new constraint that the green light packet didn’t surface. And if flags directly into HFE. Flow verification is a safety critical task and the user interface feedback design is a potential human factors engineering control.

Open items from the use process came out as four specific assignments. Each with a named owner. Engineering defines alarm latency tolerance. Regulatory and HFE classify the flow rate setting step as safety critical. Design develops the carry bag integration state. And manufacturing establishes the cannula attachment tactile feedback spec.

If you work in medical devices, you already know what comes next- HFE Plan, task analysis, formative studies, summative study, risk management file, hazard log, design FMEA- [00:14:00] these are required and they’re expensive when you start them from a blank page.

Here’s what Pierce the Design Fog concept development does to that picture. The eight step use process mapped in concept development is not a finished task analysis under IEC 62366, but it is the skeleton one is built from. The safety critical tasks -flow verification at step four, cannula attachment at step two -are already flagged. The HFE team doesn’t open a blank page. They open a documented user flow with known risk points.

The symptom impact table produced in concept development is not a finished hazard analysis under ISO 14971, but it is a starting hazard log grounded in user behavior, severity rated, with design inputs already mapped. Mechanical bypass, interlock failure -critical- go [00:15:00] straight in no blank page.

And the must have counter and the must have Kano category? That’s the team telling engineering which functions are safety critical before risk management formalizes it. Clinical reliability is must- have. Confirmed safety critical function.

This is the distinction. Traditional concept development throws a concept direction over the wall to engineering the HFE team and risk management team catch whatever lands and starts their own processes from scratch.

With Pierce the Design Fog, concept development produces outputs that hand off directly into the analysis your regulatory pathway requires. It’s a handshake, not a wall. And it doesn’t stop at concept development. [00:16:00] The use process gets iterated as the design evolves. The symptom list gets refined as you learn more. Formative studies will confirm or challenge with the concept team found here.

The starting data is concept level. The rigor gets added in engineering. What changes is where you start.

Now someone watching this will say, “We’re going to do HFE anyway. We’re going to run the hazard analysis anyway. So why does it matter whether concept development produces this material first?” Fair question. Here’s the answer. The question isn’t whether HFE and risk management will find it. They will. The question is what it costs to fix when they do, and whether your design still has room to move.

When HFE identifies a safety critical task failure in a summative study, [00:17:00] you’re looking at a design change in validated tooling. When risk management surfaces a severity five or 10 failure mode during design verification, you’re looking at a change order, a reverification loop, and a timeline impact.

When the concept development team identifies it in a session before design files open, it’s a decision. It’s fast, cheap, no ECO required. That’s why earlier is better, not because HFE and risk management will find it, because finding it later costs more and your design has less room to move.

Here’s the side by side.

For benefit prioritization: traditional concept development produced findings with equal implied weight. Pierce the Design Fog gave engineering a Kano breakdown- must- have, performance, attractive- [00:18:00] so they know what to protect first.

Failure mode visibility: traditional named the triangular risk at the project level. Pierce the Design Fog gave engineering five ranked failure modes with a specific design input for each rooted in use, not just system requirements.

A use process: the traditional method didn’t map it. Pierce the Design Fog gave engineering an eight step user journey with critical to quality ratings. Andspecific architectural constraints already flagged, including the bag interface and the thermal dissipation constraint.

Open items: With open items, traditional handed off five broad unassigned questions. Pierce the Design Fog handed off four specific gaps with named owners.

And then the two rows that matter most for this audience.[00:19:00]

HFE Task Analysis: traditional hands the HFE team a blank page. Pierce the Design Fog hands ’em a mapped use process with safety critical tasks already flagged, and a non-auditory startup constraint already on the table.

The risk management file: traditional hands risk management a blank page. Pierce the Design Fog hands them a starting hazard log, severity rated, ISO 14971- ready with design inputs already mapped for the critical and high failure modes.

The HFE team and the risk management team are going to find these things. The question is when and what it costs to act on it. When they do concept development is the cheapest place to surface them: before engineering opens a file, before a design decision is locked.

Another reason of exploring [00:20:00] concept development with a cross-functional team through these lens is the cross-functional team members themselves. They are bringing their knowledge, their expertise, their particular viewpoints, to something that is not quite defined yet. They’re able to help direct decisions and engineering choices that can affect the ultimate design decisions in the end.

Here’s a concrete example of the difference. Both methods address the same underlying concern, safety thresholds. The traditional team knew safety limits had to be defined. That’s real work. Pierce the Design Fog asked “What happens when a user interacts with those safety controls in the field?” and got a different answer. One is a requirement. The other is a failure mode with a user behavior, a consequence, a severity rating, and a design input engineering can act [00:21:00] on.

Did Pierce the design fog produce better design inputs? More of them, yes. Traced to users and failure consequences? Yes. Prioritized, yes. More work in concept development? Yes. Less ambiguity handed to engineering also? Yes. And for this audience, does it feed directly into required downstream analysis? Yes.

In medical device development, the cost of ambiguity isn’t a delayed launch. It’s a hazard you didn’t identify in concept development that surfaces in your summative study, or worse post-market.

Pierce the Design Fog doesn’t replace the HFE process you’re required to run. It doesn’t replace your risk management file. What it does do, what it does is make sure [00:22:00] concept development produces the kind of outputs those processes can actually use.

From a medical device team, that means your HFE plan and your risk management file open with a running start, not a blank page.

ClearAir is one case. I’m running the same experiment on other product concepts- links below as they publish.

The method is in Pierce the Design Fog. If you want to put it to work with your team, workshop and advisory information is in the description.

This has been a production of Deeney Enterprises.