Clinical and system requirements
Intended use, patient population, ventilation behavior, limits, alarms, user workflow and operating environment.
Historical open-source project archive
Project Omnis: an open-source ventilator engineering effort from 2020.
Outer Reef developed and published Project Omnis during the early COVID-19 response. This archive preserves the engineering context without presenting the prototype as a cleared, approved or clinically validated medical device.
- 2020 emergency-response project
- Open-source engineering archive
- Electromechanical and software system
- Not medical-use instructions
Archive status and scope
This page documents a past development effort. It does not describe an approved medical device.
Project Omnis began in the extraordinary conditions of the early pandemic. The public record shows a rapid engineering response and an open-source release; it does not establish the clinical, regulatory or manufacturing evidence required for patient use.
Do not use this archive as instructions to build or operate a ventilator for patient care. Medical-device development and use require qualified clinical, engineering, quality, regulatory and manufacturing oversight plus all applicable authorizations.
- 01
Project context
An engineering response to ventilator scarcity concerns during the early COVID-19 emergency in 2020.
- 02
Published material
The project released source material through a public GitHub repository and previously linked specification and Android application files.
- 03
System concept
The archived description included electromechanical actuation, sensors, embedded control and a mobile interface.
- 04
Evidence not established here
Clinical performance, regulatory status, production controls, validated software, alarm behavior, reliability and lifecycle evidence.
- 05
Claims removed from this page
Unverified accuracy, equivalence, cost, cost-reduction, clinical-mode and general buildability statements.
- 06
Why the archive remains
To preserve legitimate company history and show the breadth of engineering questions involved in an emergency medical-device concept.
Archived system concept
A ventilator concept is a complete safety-critical system—not a parts list.
The historical project connected actuation, airflow and pressure behavior, sensing, embedded control and an operator interface. Each layer would require defined requirements, risk controls and objective evidence before medical use.
- 1
Therapy requirements
Clinical use conditions, patient population, ventilation behavior, alarms, limits, failure response and human factors.
Qualified clinical and system inputs - 2
Pneumatic actuation
Air path, pressure, flow, volume, leakage, mechanical actuation, materials and operating envelope.
Controlled physical architecture - 3
Sensing and calibration
Sensor range, accuracy, dynamics, plausibility, redundancy, calibration, drift and fault detection.
Traceable measurement system - 4
Control and interface
Embedded states, timing, control logic, alarms, operator commands, display, data integrity and recovery.
Verified software behavior - 5
Verification and lifecycle
Requirements, risk, V&V, usability, production controls, configuration, service and postmarket responsibilities.
Regulatory and clinical evidence
Engineering lessons preserved
Emergency speed does not remove the need for system evidence.
The project illustrates why medical devices depend on connected mechanical, electrical, software, clinical, quality and manufacturing decisions.
Mechanical and pneumatic design
Actuation, load paths, air path, seals, materials, pressure, flow, leakage, wear, cleaning and service.
Electronics and power
Sensors, processors, motor drive, power sources, isolation, protection, grounding and test access.
Embedded software
States, timing, control, alarms, diagnostics, watchdogs, communication and deterministic failure response.
Operator interface
Setup, commands, displayed values, alarms, confirmations, lockouts, recovery and use under stress.
Risk and fault response
Hazards, failure modes, detection, safe-state behavior, independent protection and verification of controls.
Production and calibration
Suppliers, controlled components, assembly, calibration, inspection, test, software loading and traceability.
Evidence and configuration
Requirements, architecture, risk, reviews, test data, versions, deviations, release and lifecycle records.
Claims require evidence
A medical-device statement is only as strong as its test method and controlled configuration.
The original page made performance and cost statements that cannot be substantiated from the available material. The archive now separates historical intent from verified medical-device evidence.
Decision areaQuestion to resolveUseful evidence
Clinical performanceDoes the system deliver the required ventilation behavior across the intended patient and operating range?Qualified clinical inputs, controlled test methods, calibrated references, representative configurations and reviewed results.
Sensing and calibrationAre pressure, flow, volume and timing measurements accurate, dynamic, traceable and fault tolerant enough?Calibration standards, uncertainty, response tests, drift data, fault injection and lifecycle controls.
Pneumatic integrityDo leaks, occlusions, resistance, compliance, condensation and mechanical wear remain within safe limits?Boundary-condition tests, life testing, environmental exposure, inspection and failure analysis.
Control and alarmsAre control states, limits, alarms, watchdogs and recovery behavior correct under faults and interruption?Requirements traceability, code review, unit and integration tests, hardware-in-the-loop evidence and system tests.
Power and interruptionDoes the system manage source variation, battery state, loss of power, restart and protection correctly?Power budgets, disturbance tests, runtime evidence, alarm tests, controlled restart and configuration records.
Use and serviceCan intended users configure, monitor, respond to alarms, clean and maintain the device correctly?Human-factors work, representative-use evaluation, labeling, training inputs and service verification.
What the project record teaches
Separate an urgent concept from a device ready for clinical use.
Rapid prototyping can explore architecture and feasibility. Medical use requires a separate, controlled program for clinical inputs, risk, engineering evidence, production and regulatory authorization.
- 01
Define the medical need
Establish intended use, users, patient population, environment, therapy requirements and responsible clinical authority.
Decision outputQualified device context - 02
Develop the system architecture
Connect pneumatic, mechanical, electrical, software, alarm, user and power functions around defined risk controls.
Decision outputControlled design basis - 03
Prototype to answer questions
Use builds and simulators to assess feasibility without treating prototype results as clinical validation.
Decision outputMeasured engineering learning - 04
Build objective evidence
Verify requirements and risk controls on representative configurations with calibrated methods and reviewed results.
Decision outputTraceable V&V records - 05
Qualify production and use
Establish manufacturing, software release, quality-system, regulatory, clinical and lifecycle controls before distribution or use.
Decision outputAuthorized product lifecycle
Project Omnis archive FAQ
Historical context without medical-use claims.
These answers reflect the evidence available in the current site and public project link. They intentionally avoid strengthening unsupported performance or regulatory statements.
Why was Project Omnis created?
The project was developed during the early COVID-19 response in 2020, when ventilator availability was a major public concern. Outer Reef published an open-source engineering concept as part of that emergency response.
Can the archived files be used to build a ventilator for patient care?
This archive is not medical-use instruction. A ventilator intended for patient care requires qualified clinical and engineering requirements, risk management, verification and validation, manufacturing controls, quality-system controls and applicable regulatory authorization.
Was Project Omnis FDA cleared or approved?
The material available for this review does not establish FDA clearance or approval, and this page makes no such claim.
Are the original cost, accuracy and clinical-mode claims retained?
No. Those statements were removed because the available material does not provide the controlled test, configuration, manufacturing and regulatory evidence needed to substantiate them.
Where is the historical source repository?
The public source repository remains available at github.com/jazevedo/Omnis. Repository content should be treated as historical engineering material, not current medical guidance.
Where can I learn about Outer Reef's current medical-device work?
The Medical Device Development page describes the current engineering model across systems, mechanical, electrical, software, risk, verification and manufacturing transfer.
Current medical-device engineering
For a current device program, start with the intended use, risks and evidence required.
Outer Reef's current medical-device engineering pages explain how multidisciplinary product decisions connect to controlled requirements, verification and transfer.