Making air leaks measurable,
not a judgment call
A ventilator-integrated device prototype that continuously estimates pulmonary air leak severity by comparing delivered tidal volume with chest tube outflow — giving clinicians an objective number where today they make a visual guess.
The Clinical Problem
A real gap with no commercial solution
When a pneumothorax patient is on a ventilator, a chest tube drains the leaked air from the pleural space. Clinicians need to know how severe the leak is to decide when it's safe to remove the tube. The current method: watch the bubbling in the drainage chamber and make a subjective judgment.
There's no standardized, objective measurement. No device on the market measures pulmonary air leak severity continuously and quantitatively. Patients stay on chest tubes longer than necessary because there's no clear data-driven threshold to trigger a weaning decision — which means more hospital days, more infection risk, and more discomfort for no clinical benefit.
Clinicians assess air leak severity by watching a water-seal chamber. The observation is categorical at best, subjective in practice. No measurement. No trend data. No objective weaning criteria.
By comparing ventilator-delivered tidal volume with measured chest tube outflow, we can compute a leak differential — a real number that can be trended over time and used as a weaning trigger.
Device Architecture
Two measurement points. One differential.
The core idea is straightforward: measure what the ventilator delivers and what escapes through the chest tube. The difference is the leak. We use gas flow and pressure sensors at both points, feed the signals into a microcontroller, and compute the differential in real time.
Key Design Decisions
We don't need to know the exact air leak volume — we need to know how much of what the ventilator sent didn't stay in the lungs. A differential approach is more robust to sensor drift and calibration variance than trying to measure absolute outflow, and it maps directly to the clinical question: how much is leaking?
BME 565 is a device design course, not a clinical trial. We scoped the prototype to demonstrate the sensing principle and computation without attempting patient contact. A bench-level prototype that proves the measurement concept is the appropriate deliverable at this stage — the right next step would be animal model validation, not human use.
Before touching hardware, I designed the simulated-use workflow — the sequence of steps a clinician would follow to set up, use, and interpret the device. Starting from use first rather than specs first kept the design anchored to what the user actually needs, not just what we could build.
Regulatory Context
Designed with the regulatory path in mind
BME 565 teaches device design as a regulated practice, not just engineering. The concepts and frameworks below were part of the course curriculum and informed how we approached the design process — from risk management to use specification.
ISO 14971:2019
Risk management for medical devices. Risk identification and mitigation thinking — failure modes, hazardous situations, and acceptable risk criteria — shaped the design from the start, not as a compliance layer tacked on at the end.
IEC 62366-1:2015
Usability engineering for medical devices. The simulated-use workflow I designed follows the use specification structure from IEC 62366-1 — intended users, use environment, task analysis, use errors that could harm.
21 CFR Part 820
FDA Quality System Regulation for medical device design controls. Design inputs, outputs, verification, and validation planning — concepts that frame how a prototype like this would eventually move through a formal development process.
Project Scope
Where we are
This project completes in May 2026 with prototype testing and a final presentation. The scope below reflects the design and development phase. Test results and outcomes will be added when available.
Technical Components
Hardware + software, both sides of the signal chain
Gas flow and pressure sensors are placed at the ventilator circuit (inlet) and at the chest tube (outflow). The microcontroller computes the differential between delivered volume and measured outflow, which represents the volume leaking into the pleural space. Two measurement points, one clinically meaningful number.
Form factor matters for a bedside ICU device. The enclosure needs to be cleanable, mountable to a ventilator pole or bed rail, and interpretable at a glance by a nurse who's managing multiple patients. Early CAD work focused on those constraints before finalizing the sensing architecture — because a technically correct sensor in an unusable housing doesn't get adopted.
The device must detect and respond to sensor failures, calibration drift, and microcontroller errors. Failures are flagged to nurses with clear instructions. Failed measurements are marked unreliable; the system either switches to fallback mode or triggers a manual recalibration workflow. No silent failure.
| Failure Mode | Detection Method | Response | Recovery |
|---|---|---|---|
| Inlet sensor signal loss | Continuous impedance monitoring, alert if signal drops below threshold for more than 3 seconds | Display "Inlet Sensor: Check Connection", switch to single-sensor estimation mode | Nurse reconnects sensor, device auto-recalibrates within 30 seconds |
| Outlet sensor displacement | Pressure spike detection (sudden drop in measured outflow) | Audible alarm plus visual alert "Outlet Sensor Displaced", flag all readings as unreliable | Weekly verification protocol. Nurse confirms sensor position during routine checks |
| Calibration drift (greater than 2 percent over 24 hours) | Internal reference signal check every 4 hours, compares current baseline to initial calibration | Display "Recalibration Recommended" after 24 hours continuous use | One-button recalibration. Device runs 60-second baseline capture with known zero-flow state |
| Microcontroller hang | Hardware watchdog timer (60-second timeout) | Automatic system reset, preserves last 30 minutes of data in non-volatile memory | Device restarts in less than 10 seconds, resumes monitoring with last-known calibration |
What I've Learned So Far
The gap between concept and prototype is mostly process
Before I touched any hardware or CAD, I spent time in the literature on air leak monitoring methods — existing research, tried approaches, why they didn't become commercial products. That review moved us away from our first-pass concept (simple flow meter at the chest tube) toward the differential approach. The hard design decisions got easier once we understood why no one had solved this with a simpler method.
The instinct in an engineering course is to start with what you can build and work backward to a use case. I pushed us to define the simulated-use workflow first: who uses this, in what environment, under what time pressure, with what prior training? That kept us from designing a device that would work in a lab but not in an ICU. The use specification flagged constraints — alarm management, cleanability, one-handed operation — that would never appear in a component-level spec.
Working through ISO 14971 risk analysis during the design phase — not after — caught at least two design choices that could have created hazardous situations. Sensor failure modes, alarm conditions, and edge cases in the differential computation aren't obvious until you ask the question: what happens if this fails, and who gets hurt? Running that analysis early changed the design, not just the documentation.
Post-Mortem
What I got wrong.
Most case studies end on the win. This one doesn't. If you're interviewing me, these are the things I'd want you to ask about.
Early in the design I spec'd a pressure transducer based on range and cost, not on the noise characteristics at the small differential pressures this device actually measures. When I wired up the first bench prototype, the sensor's inherent noise was the same order of magnitude as the signal I was trying to detect. I had to add aggressive smoothing to compensate, which introduced latency into the alarm path. The lesson is boring and I now believe it: start the sensor selection from the signal you need to preserve, not from the part's datasheet top-line spec.
My first alarm logic was a simple threshold: if the differential pressure exceeds a value for 200 ms, alarm. In simulated use, the alarm triggered correctly on real leaks and also triggered on patient coughs, chest-tube repositioning, and ambient pressure swings when a door opened. A clinician who hears a false alarm three times an hour starts ignoring all alarms. I had to rebuild with hysteresis, a rolling-average threshold, and a debounce timer. In hindsight, the IEC 60601-1-8 alarm standard exists specifically to prevent the mistake I made, and I should have read it on day one instead of day sixty.
I spent the first six weeks reading clinical literature and thinking about engineering. When I finally described the device to a nurse with ICU experience, she told me in 90 seconds that the mounting location I'd assumed was wrong, the one-handed operation requirement was real, and the alarm-silence button had to be larger than I'd sketched because gloves. Those three comments reshaped the industrial design and the firmware. None of that would have come out of more literature review. Next project, I'm showing a paper sketch to a clinician before I open CAD.
Questions You Might Ask
Answers before the interview.
If I were screening this portfolio, these are the three questions I'd ask. So here they are, answered.
Choosing differential pressure over flow-rate detection. Flow was simpler to instrument, simpler to explain, and two existing research devices had already tried it. I spent a week working through why those research devices hadn't matured into products and concluded the signal-to-noise problem was fundamental at clinical leak rates. Differential pressure added complexity in the sensor array and calibration, but gave us a signal that was actually above the noise floor in the operating range we cared about. If I'd picked flow, we'd have a device that worked in a lab and failed in a patient room. I'd make the same call again.
My capstone advisor, who pushed back on my first concept hard enough that I had to defend it or drop it. I dropped it. A respiratory therapist I interviewed who described, in detail, how clinicians currently estimate air leaks by watching water columns in drainage chambers, which is how I understood the clinical inertia around the existing approach. And the two classmates on my team who built out the enclosure CAD and the battery subsystem while I focused on signal chain and alarm logic. This was never a solo project.
I'd run a formative usability study with at least three ICU nurses and a respiratory therapist before finalizing the user interface. Right now the interface decisions are defensible but based on one informal conversation and literature. Summative validation would still require a clinical environment and ethics approval we don't have academic access to, but formative work is cheap and I should have planned it in from week one. Second, I'd instrument the prototype with data logging so every bench test produces a record I can hand to a reviewer. The ad-hoc test notes I kept are fine for a class project and insufficient for a design history file.
Looking for a role where the engineering has real clinical stakes
This project is the clearest expression of what I want to do professionally: find a gap where the clinical need is obvious and the engineering solution is non-trivial, then build it. I'm finishing my M.S. in Biomedical Engineering at Stevens and looking for R&D, validation, or applications engineering roles in SoCal medtech.