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. Gives 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. This 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 are concepts that frame how a prototype like this would eventually move through a formal development process.
Project Scope
Where we are
Final paper, final presentation, and bench-tested prototype shipped. Four balloons (intact, slight, moderate, severe) were tested on a benchtop rig with pressure-based severity classification on a 16x2 LCD. Bench test table and the FS3000 sensor saturation finding are documented in the Bench Test Results section below.
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. 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. These 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.
Bench Test Results
Four balloons, four severity tiers, real numbers.
An Ambu bag and a T-piece manifold push air into a balloon that simulates the lung. Each balloon represents a different leak severity. The MPRLS pressure sensor reads gauge pressure inside the simulated pleural cavity. Steady-state held pressure is what the LCD classifies.
| Test condition | Held pressure (cmH2O) | LCD classification |
|---|---|---|
| Intact (sealed balloon) | 31.0 | Damage: NONE |
| Slight leak (pinhole) | 17.0 | Damage: SLIGHT |
| Moderate leak (medium puncture) | 12.9 | Damage: MODERATE |
| Severe leak (large breach) | 10.5 | Damage: SEVERE |
Pressure readings cleanly separated the four tiers, monotonically decreasing as severity increased. Classification thresholds (24, 15, 11.5 cmH2O) sit at the midpoints between adjacent calibration values, giving margin on either side. The LCD switched between tiers in real time as balloons were swapped, with no flicker at boundaries.
Honest finding on the flow sensor. The FS3000 returned values at or near maximum range during pressurization across all four balloons and near zero during the held phase. Neither phase varied with severity, which is what drove the pivot to pressure-only classification. The FS3000 still reads on the LCD as a sensor-status indicator, but it does not contribute to the severity decision in this rig. See the post-mortem section below for the full debrief.
Custom 3D-printed adapter. The FS3000 ships as a small breakout with a 7.8 by 4.0 mm rectangular flow channel and no native fitting for laboratory tubing. I designed a parametric saddle-cap adapter that mates to the module on its inner side and transitions to a 6 mm ID barb on the outer side. Two adapters were printed on a Bambu Lab FDM printer with silicone sealant for an airtight seal. The adapter is parametric so tubing ID can be changed in one line and regenerated. Without this part, dual-sensor characterization on the bench rig would not have been possible.
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.
The original design used a Honeywell MPRLS pressure sensor and a Renesas FS3000 flow sensor on a shared I2C bus. The classification logic took the higher of the two severities to be conservative. When I ran the four-balloon bench test, the FS3000 saturated at maximum range during the pressurization phase across all four balloons and dropped below useful resolution during the held phase. It did not discriminate severity in this rig. I pivoted to pressure-only classification and kept the FS3000 reading on the LCD as a sensor-status indicator. The lesson: characterize each sensor in the actual operating envelope before locking the classification logic. The FS3000 was spec'd for HVAC airflow ranges, not the brief high-velocity transients my Ambu bag produces. I would still pick a flow sensor for v2; I would just pick one with a higher saturation ceiling and run a saturation-bound test before integrating.
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.
Three changes. First, swap the FS3000 for a flow sensor with a higher saturation ceiling and run a sensor-bound test on the bench rig before integrating it into the classification logic. The dual-sensor design was sound; the part choice was wrong. Second, run a formative usability study with at least three ICU nurses and a respiratory therapist before finalizing the user interface. The current interface decisions are defensible but based on one informal conversation and literature. Formative work is cheap and I should have planned it in from week one. Third, instrument the prototype with structured 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.