Plain-language wisdom on Lean Six Sigma

That is a system interaction noise factor, the same kind that sinks a well designed device in the field: the product works, but something it depends on fails.

Most resilience plans are verified at nominal. The Design For Lean Six Sigma fix is to define the CTQ in the customer’s terms (“card payment approved in seconds,” not “99.9% uptime”), put single zone loss, a slow third party API, and peak traffic on the P-diagram, and test each one before it shows up as a live incident.

If a noise factor has no test against it, the gap isn’t in your runbook. It’s in your design.

Google says cloud outage affecting UK banks and websites resolved (BBC News)

Epic came after the workflow, to make the handoff repeatable. The results speak: a provider in under 20 minutes, left-without-being-seen below 0.5%, admission order to ED departure 43% faster, and bed assignment to departure down from 68 to 42 minutes, all while volume rose.

What stands out is the sequence. They fixed the process, held it as standard work with daily scorecards, proved it at one hospital, then spread it to twelve. That is Lean improvement done well. The next step is design. When a new service or discharge process is built from scratch, that same discipline of one metric, one owner, and a date belongs at the start, before the waits appear.

How One System Reduced ED Wait Times Without Expanding (Medscape)

Medical device teams still fold verification, validation, and transfer into one DFSS “Verify” box. That’s convenient on a slide. It’s wrong under design controls. Verify is not Validate. Validate is not Transfer. Each answers a different question and needs its own evidence.

That is the case for two companion preview apps; not a QMS of record:

• MedDFSS Application authors the DFSS model from the start.
• MedDFSS Audit inventories company DHF / Design and Development File and DMR / Medical Device File documents and reports coverage gaps.

Why DFSS Needs Validate & Transfer as Separate Phases (MDDI)

Both failures described here are classic noise factor problems more than isolated bugs. A re-registration step that needs Wi-Fi or cellular access collides head-on with the ambulances, aircraft, and remote settings Lumify was built for. A USB connection that can drop mid-scan is exposed to cable flexing, handling, vibration, and the wide variety of phones and tablets it plugs into. These are the conditions that robust design is meant to anticipate.

A Robust Design FMEA organized around the five noise sources (piece-to-piece variation, wear out over time, customer usage, the external environment, and system interactions) forces those questions early. What happens when there’s no network? When the cable is flexed for the thousandth time? When the host device updates its OS? Each answer should become a design input and a design verification stress test, with a safe failure mode such as offline operation or graceful recovery, before the device reaches the field.

The interim guidance to use the device only where there’s reliable signal and to keep backup imaging on hand is prudent. It also shows the cost of finding these noise factors after launch rather than designing against them up front. I hope the root cause work on the cable issue feeds back into design controls and the risk file, not just a software patch.

Four Deaths Linked to Philips Lumify Ultrasound Glitch (MDDI)

A CAIO who owns that rigor can walk an auditor from the claim to the architecture, the data, human factors, and cybersecurity, and then to the verification evidence. That walk is what MedDFSS is for.

The Application authors it on the DFSS spine, Define through Transfer, while the design and development plan is still open. Each AI-enabled claim becomes a CTQ traced to a design output, the measurement system behind it, a hazard and a residual risk decision, human factors, cyber (threat, control, and V&V), and a verification or validation method. If AI is in scope, Define stays open until the device software function is declared. The change control plan and the post market drift pointer are carried into Design and Validate or the gap is recorded on purpose. MedDFSS Audit then asks the question an auditor will ask: do the company’s design history and device master records actually cover that model?

The governance frameworks Claire Wallace describes hold when they are written in at the start. Algorithmic fairness and patient safety belong on that same trace, as design inputs and residual risk decisions. If your CAIO cannot point to validated process evidence and a living risk file for each AI enabled claim, you do not have an AI strategy. You have a compliance gap waiting for an auditor.

Meet the C-Suite Role Every Medtech Company Is Adding (MDDI)

The fix is not a colder handoff or a prettier prototype. It is locking a manufacturable design before formal verification: CTQs tied to process capability, tolerances justified against real variation (not tribal preference), and materials/methods that scale not only just print. In DFSS that lock is a freeze: Design is complete enough only when the CTQs, a first pass DFX, and justified tolerances sit with a process concept and a trace that already names verify methods. Only then do you spend Verify. That freeze is not the company design review; those records stay in the QMS. The rule is simple just do not start V&V on a design that only works on the bench.

MedDFSS Application makes that visible, currently is a working papers. On one over constrained print you can try TOOL-CTQ; (what must be held), TOOL-DFX; (will it manufacture and assemble), TOOL-TOL; (tighten only what drives a CTQ), and TOOL-TRACE; (need → CTQ → output → verify method). Completeness is the model plus those worksheets, not a prettier CAD file. It is not the DHF and not the QMS of record.

James and Don, if a current OEM print has the over tolerance problem you describe, those four worksheets are enough to test whether the freeze would have caught it before design verification testing.

How OEMs & Contract Manufacturers Partner to Eliminate Early-Stage Medical Device Design Pitfalls (MDDI)

Humidity, power loss, anatomy shift, and out of distribution inputs are environmental / system noise. Override, disagreement, and workflow ambiguity are user noise. Hunt all five noise buckets early, coupled to the claim but don’t scramble after the claim hardens.

That is DFSS: turn the playbook into CTQs and robust design, not a longer list. MedDFSS Application and MedDFSS Audit are working in progress solutions available now for teams that need to finish development the right way: Application authors the DFSS model (CTQs, tools, traces); Audit checks whether company DHF/DMR documents cover it. Neither is the QMS of record.

Happy to share a look if useful for your October 2026 MD&M Midwest session or for teams interested.

Navigating Regulatory Changes When AI Moves From Screen to Surgical Robot (MDDI)

Under design controls, the lean move is not to turn the draft into a checklist. Translate each recommendation into CTQs with measurable tolerances: scaling ratio linearity across the workspace; intentional motion preservation versus tremor attenuation; disturbance rejection so console jolts do not become tip motion; predictable stop, recovery, and emergency access timing. Then treat clinical and environmental uncertainty (speed, envelope position, impulse forces, fault modes) as noise factors in robust design. That produces verification evidence that those CTQs hold under compound conditions, the consistency the draft is asking teams to show.

That is what MedDFSS Application authors: CTQs, P-diagram noise, the robustness / DFMEA worksheets, and the need → CTQ → output → V&V trace as working papers. It is not the premarket file and not the QMS of record. Official records stay in the company document-control system.

FDA Issues Draft Guidance on Robotically Assisted Surgical Devices (MDDI)

Those mechanics only hold if they are designed as controls and captured as design outputs from the start — not bolted on after bench verification. A useful DFSS move is to treat use and foreseeable misuse as user noise on the P-diagram (shift change, new hire, wrong load), walk them in the DFMEA, and send use-error to validation, not design verification.

That is what MedDFSS Application authors: user needs and CTQs, the noise/FMEA/robustness worksheets, the need → CTQ → output → V&V trace, and a usability sheet for tasks in actual or simulated use. It is a working-paper workbench, not the DHF and not a full 62366 execution suite. Official records stay in the company QMS. The evidence to keep is how the UI reduces variation in safe use under real workflow stress — not merely that a summative study was filed.

Why Human-Centered Design Is Essential for Modern Medical Devices (MDDI)

What those OEMs audit next is whether the converter can hold CTQs after the job leaves the prototype lab, the selective adhesive and multi press builds he describes, die cut filters, serialized labels. That takes process validation with clear acceptance criteria, MSA that can see the tolerances claimed, and change control that revalidates when adhesive, liner, or press recipes move.

A lab that turns a CAD file into evaluable parts in about a week is a strong start. He already draws the line: prototype in a week, production press in four to six. Closing that gap is proving the same CTQs survive tooling, web, and lot variation. Not the certificate on the wall.

That is the split we built into MedDFSS. Application authors the CTQ, MSA, and transfer and process validation model so the how to is explicit. Audit then asks whether company DHF / DMR documents actually cover that model. Neither app is the QMS of record. The certificate gets you on the list; the evidence keeps you there.

From WWII Aircrafts to Medical Device Innovation: Inside Topflight’s 80-Year Evolution (MDDI)

MedDFSS Audit then asks a different question: do the company’s controlled Design History File (DHF) documents actually cover them? A compliant looking stock keeping unit (SKU) with no SPDF, no SBOM, and no cyber chain shows up as a coverage gap. Isolated SKUs that leave cyber off are not applicable (N/A) not a pass. Neither of the apps are the quality management system (QMS) of record; both sit upstream of electronic document management / 21 CFR Part 11.

Device SBOM theater without a living evidence trail is the same category error as manufacturing information technology / operational technology (IT/OT) that never enters the risk file. The product can look ready. The chain that makes and supports it is not.

What FDA’s AI guidance trajectory (lifecycle evidence, change control, risk-proportionate monitoring) is really asking for is the same discipline Design for Six Sigma always required: clear CTQs, traceable decisions, and an expected-evidence pack before documents lock in the QMS. “The model said so” is not a design input. “Here is the claim, the risk control, the verification, and what we will monitor after release” is.

The teams that win won’t be the ones prompting hardest. They’ll be the ones who can show an inspector how AI-assisted design artifacts connect to user needs, risk, and process capability — especially as GenAI frameworks keep evolving.

How Generative AI Is Reshaping Medical Device Design (MDDI)

FDA AI Medical Device Guidelines 2026: Expert Legal Perspective on Compliance (MDDI)

Under QMSR inspection pressure, investigators follow threads: complaint → CAPA → risk management → design/process controls. If your expected evidence wasn’t defined upstream, you’re reconstructing the story under heat.

Recalls are expensive teachers. The cheaper lesson is closing the gap between “model completeness” (what the DFSS/process plan said you’d prove) and “controlled-doc coverage” (what actually sits in the DHF/DMR) before the field teaches you.

Inside August’s Biggest Device Recalls (MDDI)

1,081 Injuries Prompt Boston Scientific to Recall Spinal Cord Stimulation Leads (MDDI)

What I’d add from Design for Six Sigma practice: treat prioritization as an evidence problem, not a meeting problem. VOC / CTQs, tangible concepts for reaction (not ranking vague lists), and a living downselect (“now / later / high / low”) that survives value-engineering joining late. When that evidence trail is weak, you get the role collision he describes — product wants perceived value, VE wants cost, and nobody can show which CTQ actually moved.

Front-end discipline isn’t only for moonshots. It’s how you keep design controls and manufacturing tradeoffs coherent through mid-program change.

Front End Innovation: Not Just for the Front End Anymore (MDDI, by Eric Olson, Starfish Medical)

Map DMADV onto a campaign the same way you’d map it onto a product: Define the CTQ as a number (cost per qualified lead, not “more awareness”), Measure the real baseline instead of assuming it, Analyze which levers actually move the number versus which ones just correlate, Design the funnel against that evidence, and Verify with a limited-spend pilot before the full budget commits.

The control-factor / noise-factor split carries over too. Creative, offer, targeting, and cadence are control factors — the team sets them. Seasonality, ad-platform algorithm changes, competitor moves, and sales-team follow-up capacity are noise — the market sets them. A campaign only ever tested under a good launch week has been verified at nominal, and that’s the same failure mode as a design that only ever gets tested at room temperature.

Download the full white paper (PDF)

A “Watch” status on a DV matrix is a diagnosis, not a fix. A normal DOE asks which control factors move the response. A robust parameter design DOE asks a sharper question: which control-factor setting makes the response stop caring about the noise?

• Put only the noise-sensitive control factors in the inner array — against an outer array built from the noise levels already defined in the P-Diagram and DV plan
• Look for the setting where the response stays flat across noise levels, not just the one that hits target at nominal
• Confirm the winning setting at the exact worst-case compound condition, then feed the result back into the DFMEA and verification plan

A “Watch” status is an instruction to run this experiment, not to retest and hope. Chasing the mean without measuring variance across noise just produces a design that passes today’s test and fails next year’s field conditions.

P-diagram helps in listing noise and control factors and becomes a bridge to a robust design verification Matrix.

• Control factors → your DV setup parameters (what you hold constant, what you deliberately vary to find the optimum)
• Noise factors → your DV stress conditions (what you must show robustness against, often via worst-case or combination testing)
• Ideal function / response → your DV pass/fail criteria

If a noise factor has no corresponding verification condition, that’s not a gap in your test plan — it’s a gap in your risk coverage. The P-Diagram doesn’t just explain how the system behaves; it tells you exactly what you still owe the design before you can trust it.

Download the full white paper (PDF)

Every noise factor you’ve mapped piece to piece variation, changes over time, customer usage, external environment, and systems interactions is a candidate stress condition for verification. Every control factor is a candidate lever you deliberately set and hold during that test. Together they define the envelope your design must survive, not just the inputs your design must accept.

The discipline is this: don’t let control factors quietly absorb what should be tested as noise.

1. Piece-to-piece variation
2. Changes over time/degradation
3. Customer usage/duty cycle
4. Environmental factors
5. System interactions

A failure mode with only single cause relationship hasn’t been fully analyzed, it is been partially analyzed. The real value of the P-Diagram isn’t the diagram itself, it is the forcing function it creates. It stops the team at each failure mode and asks, “have we checked all five sources, or did we stop at the first one that came to mind?” And that what is called MECHANISM OF FAILURE!

The habit to build: treat the five noise categories as a mandatory pass/fail checklist per failure mode not a menu to sample from. That is what turns a DFMEA from “what we’ve seen before” INTO “what could actually happen.”

A Design FMEA asks a deceptively simple question: how can this design fail? But “failure” only makes sense relative to an intended function. Without first mapping what the product is supposed to do, and everything acting on it while it does that, teams tend to brainstorm failure modes from memory and past experience alone. That approach reliably misses failure modes that haven’t happened yet which is exactly the population of risks a Design FMEA exists to catch.

The mistake I see most often: teams treat risk assessment like a checkbox. Run an FMEA once, file it, move on. Then they're surprised when the "fix" they roll out in Improve introduces a brand-new failure mode nobody caught.

Real risk management doesn't live in one phase. In Define, it's asking what could make this project fail before you've spent a dollar on it. In Measure, it's questioning whether your data collection itself is introducing bias or missing failure conditions. In Analyze, root cause and risk are the same conversation — every root cause you find is a risk source you haven't controlled yet. In Improve, the discipline is asking "what new risk does this fix introduce" before you roll it out, not after you've already broken something else. And in Control, risk management is the entire point — your control plan only works if it's built to catch the failure modes you already identified.

The tell I use: if your risk assessment is a document you produced once and filed away, it's compliance theater. If it's a question you're re-asking at every DMAIC gate, it's actually managing risk.

DMAIC (Define, Measure, Analyze, Improve, Control) is for fixing something that's already running. DMADV (Define, Measure, Analyze, Design, Verify) — the core of Design for Six Sigma — is for building something new, or for processes so far from capable that incremental fixes will never get you there.

Get that choice wrong, and here's what it actually costs: months spent optimizing a process that was never going to hit its target performance no matter how many DMAIC cycles you run — because you're refining a design flaw, not a process defect. Teams often end up paying twice: once for the failed improvement effort, then again when they finally admit they needed to design it right from the start.

The tell I look for: if you're asking "how do we make this better," you probably want DMAIC. If you're asking "does this need to exist in a different form entirely," you need DMADV.

A kitchen during a Friday dinner rush and a biologics production line have the same failure modes — unclear handoffs, no standard work, and everyone firefighting the same problem every week without ever asking why.

The tools scale up and down. The discipline of asking "why does this keep happening" doesn't change.