Project Omnis was an open-source ventilator engineering effort that Outer Reef published during the early COVID-19 response in 2020. It belongs in the company record as an emergency design project, not as a current medical product.
The available material does not establish FDA clearance or approval, clinical validation, production use, patient outcomes, or equivalence to a commercial ventilator. This retrospective removes those unsupported claims and focuses on engineering practices that remain useful: scope control, cross-disciplinary interfaces, user research, safety architecture, configuration records and transfer planning.
The emergency context changed the work
In 2020, the demand for respiratory equipment drove many public, academic and commercial engineering efforts. FDA created emergency policies and authorizations for specific devices and accessories. Those pathways did not make every open-source design authorized for medical use; authorization remained tied to defined products, evidence and conditions.
The FDA now treats this material as historical COVID-19 emergency information. A prototype or source repository from that period should not be interpreted as current instructions for building or using a medical device.
Lesson 1: define the intended use before the architecture
“Ventilator” describes a broad category with very different clinical uses, modes, patient populations, environments and controls. Architecture decisions depend on the intended therapy, users and conditions. Pressure and flow ranges, oxygen delivery, triggering, alarms, battery behavior, circuits, humidification and patient interfaces cannot be selected responsibly without that context.
Emergency projects can be tempted to begin with available components. Availability matters, but it does not define a safe intended use. Start by writing what the system is meant to do, who will operate it, where it will be used, and what is explicitly outside scope. Record every assumption that still requires clinical or regulatory input.
Lesson 2: assign ownership for requirements and decisions
Fast work creates a large flow of suggestions, drawings, code changes and component substitutions. A team needs clear authority for product requirements, clinical questions, system architecture, risk, configuration and release. Without ownership, a suggestion can become an accidental requirement and an experimental result can become an unsupported claim.
Use a decision log that identifies the question, options, evidence, reviewers, decision and affected artifacts. The record matters more when people work remotely and cannot rely on informal context.
Lesson 3: remote research needs an explicit evidence plan
Pandemic restrictions made normal observation and in-person formative work difficult. Remote interviews and interface reviews can still reveal workflow, terminology and information needs, but they may not show physical reach, force, cable interaction, alarm audibility or team movement accurately.
State what each method can answer. A screen-sharing session may test information hierarchy. A mailed mockup may support a limited handling study. A video walkthrough may expose room layout and team communication. None should be described as full validation unless the users, tasks, conditions and product configuration support that conclusion.
Lesson 4: build safety around sensing, control and alarms
A respiratory system couples pneumatic components, sensors, actuators, control software, user settings, patient circuits, power and alarms. A value shown on a display may depend on sensor range, calibration, sample location, tubing, filtering, timing and compensation. A commanded actuator position is not the same as delivered patient flow or pressure.
| System area | Evidence questions |
|---|---|
| Pressure and flow sensing | Range, accuracy, drift, calibration, condensation, occlusion and fault detection |
| Control behavior | Timing, stability, saturation, transitions, interrupted power and sensor failure |
| Alarms | Priority, limits, delay, audibility, visibility, latching, silencing and recovery |
| Pneumatic path | Leaks, resistance, compliance, valves, filters, connections and contamination |
| User interface | Setting confirmation, displayed units, mode awareness, critical tasks and foreseeable misuse |
Safety work should include hazard analysis, fault behavior and verification of each risk control. A normal-operation demonstration is only a starting point.
Lesson 5: configuration records make collaboration credible
Distributed teams need to know which hardware, firmware, application, calibration and test setup produced each result. Shared file names and screenshots are not enough. Use unique versions, controlled interfaces, build records and issue tracking.
For each experiment, preserve the question, unit configuration, method, instruments, raw data, result and limitations. This prevents a later revision from inheriting a claim that was demonstrated on a different configuration.
Lesson 6: design transfer is a separate engineering problem
A prototype assembled by its designers is not a production system. Transfer requires complete specifications, qualified suppliers, repeatable assembly, inspection and test methods, calibration, software release controls, labeling, packaging, service and traceability.
Parts described as readily available can change, become counterfeit or vary among suppliers. A substitution may affect pneumatics, sensing, materials, firmware timing or electromagnetic behavior. The design needs controlled acceptance criteria and a change process rather than an informal bill of materials.
What the original article overstated
The 2020 article claimed commercial-ventilator functionality, specific modes, rapid assembly, low component count, affordability and ISO 13485 compliance. The available evidence for this review does not support those statements, so they are not repeated here.
Project history is strongest when it distinguishes aspiration from demonstrated evidence. An open-source release can show engineering intent and public contribution without implying clinical readiness.
What should remain in the archive
The archive should preserve the project name, 2020 context, source repository, major design questions and lessons. Original files can remain available as historical engineering material when they carry a clear status and safety boundary.
Any photograph should identify the actual item and date. Any performance figure should identify the tested configuration and method. Downloads that resemble build or operating instructions should make clear that they are historical and are not current medical guidance.
How the lessons apply to current device programs
The pressure of the pandemic made common product-development weaknesses visible: unclear scope, missing inputs, interface assumptions, late user feedback and incomplete transfer planning. The corrective practices are useful in ordinary programs as well.
Define the intended use and evidence strategy early. Attack the uncertainties that can change architecture. Keep requirements, risk, interfaces and configurations connected. Treat clinical, human-factors, verification and manufacturing work as part of the product rather than final documentation.
The Project Omnis historical archive preserves the project boundary and source link. Outer Reef’s current medical-device development, medical software and quality and regulatory engineering pages describe present-day services.
