A transport ventilator has to do everything an ICU machine does while weighing what a laptop bag weighs. Hamilton Medical lists the T1 at 6.5 kg with 8 hours of battery on two cells, or 4 hours on one. ZOLL lists the EMV+ at 4.4 kg with 10 hours. Dräger lists the Oxylog 3000 plus at 5.8 kg in a 290 by 184 by 175 mm body. Those three numbers set the envelope every new program is measured against, and none of them leave room for a comfortable architecture.
At OVA Solutions we are experienced medical device hardware developers, 62 engineers with more than 200 shipped devices behind us. The program described here was a full-cycle build: requirements, concept, industrial and mechanical design, electronics, embedded software, preclinical testing, and production handover. The client needed hospital-grade ventilation modes, closed-loop gas mixing, capnography, and a hospital network connection, all running from an internal battery. The engineering answer was not one clever board. It was ten of them.
Why the electronics split into ten boards
The instinct on a size-constrained device is to consolidate. Fewer boards mean fewer connectors, less copper, less volume. On a life-support device that instinct is wrong, and the reason is verification rather than physics.
The system partitioned along safety boundaries. Real-time respiratory control ran on an STM32F446 with the pressure sensors and the DAC outputs on the same board. Oxygen and air mixing ran on its own unit with galvanic isolation and its own MCU, because a gas-ratio fault is a different hazard class from a display fault. Capnography got a dedicated controller with the CO2 sensor and its own sample pump driver. Battery management sat alone with a BQ40Z80 balancing four Li-Ion cells. The user interface, a 10-inch flexible display and a capacitive keypad with haptic feedback, ran on an i.MX8 QuadMax carrier with a Coral edge TPU for on-device processing.
That split costs volume. It buys something more valuable, which is a small blast radius during verification. When the interface team changes the ventilation-mode UI in month fourteen, the respiratory control loop does not re-enter verification. Its firmware did not change, its board did not change, and the isolation barrier between them is documented. On a device governed by IEC 62304 software safety Class C, that boundary is the difference between a two-week regression cycle and a two-month one.
Newcomers to Class II hardware usually hear board partitioning described as an EMC or thermal decision. On life-support devices it is primarily a documentation decision that happens to also help EMC.
The decision that cost the most schedule
The piezoelectric proportional valves that meter gas flow are driven by dedicated modules. Buying those modules is the obvious call: they exist, they are qualified, and they keep a line item off the BOM sheet and out of the design history file.
The purchased module did not fit. It was too large for the pneumatic block, and its slew rate capped how fast the valve diaphragm could move, which capped the responsiveness of the whole breath-delivery loop. The supply voltage range also assumed mains power rather than a battery rail sagging under load.
The team built a replacement, designated PD450, around a two-phase boost controller and a micropower comparator. It came in at half the volume of the purchased part and drove the valve 2.5 to 3 times faster, which moved the ceiling on breath-delivery responsiveness rather than just the parts count. The supply range was wide enough for battery operation. A separate current-limiting board was added underneath it, because a piezo actuator presents as roughly a 15 microfarad capacitor and will happily pull whatever the driver stage can source. Two independent limiting channels with a bimetal thermostat backstop solved the thermal case.
The engineering result was good. The schedule result was not, and the reason is worth stating plainly: a build decision fails on the bench in month three, while a buy decision fails at integration in month eleven. Both are recoverable. Only one of them is recoverable cheaply.
The applied version of this for any program director: make-vs-buy on the critical path should be decided against the physics envelope during concept, not against the BOM during layout. Write down the parameter that would disqualify the purchased part, measure it on a sample before the mechanical design freezes, and treat an unmeasured assumption about a bought component as an open risk rather than a closed line item.
Where the calendar actually goes
Analysis by Medical Design and Outsourcing put the median time from concept to 510(k) clearance at roughly 31 months. The FDA review clock itself is about 90 days. Everything between those two numbers is verification and validation.
For a ventilator that means performance testing against ISO 80601-2-12, alarm-system conformance under IEC 60601-1-8, usability engineering under IEC 62366-1, risk management under ISO 14971, EMC, transport vibration, altitude, and software validation at Class C. None of that work can start before the design is stable, and all of it restarts to some degree when the design moves.
The practical consequence is that schedule compression does not come from designing faster. It comes from designing in a sequence where the safety-critical subsystems freeze first and the cosmetic ones freeze last. On this program the respiratory control board and the gas-mixing unit were locked well ahead of the interface stack, which continued to change while verification ran on everything underneath it.
What we would tell a program director starting today
Freeze the safety-critical MCU and its board before anything else, and accept an interface that looks unfinished for another two quarters. Partition boards by verification domain rather than by mechanical convenience, and write the hazard boundary into the architecture document so the rationale survives staff turnover. Decide make-vs-buy against measured physics rather than catalog specifications, and put the disqualifying parameter in writing. Give the power path a named owner from week one, because on a battery-operated life-support device the power architecture constrains the pneumatics, the compute, and the enclosure simultaneously. Budget preclinical testing into the original plan rather than treating it as the phase that follows engineering.
The program reached preclinical trials and production handover. Mordor Intelligence valued the portable ventilator segment at roughly $1.08 billion for 2026, growing at just over 5 percent a year. In a market moving at that pace, the programs that arrive first are rarely the ones that designed fastest. They are the ones that decided earliest which subsystems were still allowed to change.
Common questions
Why did the ventilator electronics split into ten boards instead of one
The boards were partitioned along safety boundaries rather than mechanical convenience. Real-time respiratory control, gas mixing, capnography and battery management each sat on their own unit, so a change on the non safety-critical side does not drag the safety-critical side back through verification. Under IEC 62304 software safety Class C that boundary is the difference between a two-week regression cycle and a two-month one.
What did the make-vs-buy decision cost the program
The purchased piezo valve driver module was too large for the pneumatic block, its slew rate capped breath-delivery responsiveness, and its supply range assumed mains power rather than a battery rail. The replacement, designated PD450, came in at half the volume and drove the valve 2.5 to 3 times faster. A build decision fails on the bench in month three, while a buy decision fails at integration in month eleven.
How long does a Class II portable ventilator take from concept to clearance
Analysis by Medical Design and Outsourcing puts the median time from concept to 510(k) clearance at roughly 31 months, while the FDA review clock itself is about 90 days. Everything between those two numbers is verification and validation, and none of it can start before the design is stable.
Which standards apply to a portable ventilator
Performance testing runs against ISO 80601-2-12, alarm-system conformance under IEC 60601-1-8, usability engineering under IEC 62366-1, and risk management under ISO 14971. Software is validated at IEC 62304 Class C. EMC, transport vibration and altitude testing apply as well.
How heavy is a portable ventilator allowed to be
Hamilton Medical lists the T1 at 6.5 kg with 8 hours of battery on two cells. ZOLL lists the EMV+ at 4.4 kg with 10 hours. Dräger lists the Oxylog 3000 plus at 5.8 kg in a 290 by 184 by 175 mm body. Those three numbers set the envelope every new program is measured against.
Sources: Hamilton Medical, HAMILTON-T1 specifications · ZOLL, EMV+ 731 series specification sheet · Dräger, Oxylog 3000 plus datasheet · Medical Design and Outsourcing, 510(k) time and cost analysis · FDA, Premarket Notification 510(k) · Mordor Intelligence, portable ventilators market · IEC 62304:2006+AMD1:2015 · ISO 80601-2-12:2023 · IEC 60601-1-8:2006+AMD1:2012+AMD2:2020 · IEC 62366-1:2015+AMD1:2020 · ISO 14971:2019