• Define intended purpose, patient population, users, clinical workflow, operating environments, accessories and system boundaries. 

• Apply ISO 14971 risk management to identify hazards, sequences of events, hazardous situations, harms, risk controls and residual-risk decisions. 

• Identify the applicable general and particular standards using the product’s modality, classification, intended use, markets and current regulatory requirements. 

• Allocate measurable safety requirements across hardware, software, mechanical design, accessories, user interface and operating procedures. 

• Plan verification and validation early, linking every risk control and requirement to a method, acceptance criterion and retained result. 

• Maintain change control, configuration management, production controls, complaint handling and post-market feedback throughout the lifecycle. 

Application-specific safety and security challenges 

Circuit disconnection, leak or obstruction: A patient circuit separates, leaks, kinks or becomes obstructed; detection depends on mode, sensor location and patient/circuit characteristics. 

Incorrect pressure, volume or flow: Sensor drift, valve sticking, calibration error, control instability or software defects cause delivered support to differ from the target. 

Oxygen concentration or gas supply fault: Supply pressure, blender, sensor or connection failure changes delivered gas composition or reduces available support. 

Alarm delay, suppression or confusion: Alarm logic, thresholds, latency, priority, muting or competing alarms delay recognition of a hazardous condition. 

Power interruption or depleted battery: Mains loss, battery degradation, charger fault or switchover behaviour interrupts respiratory support. 

Condensation, secretions or filter loading: Environmental and patient-side conditions alter sensing or gas-path resistance. 

Mode, parameter or interface error: Incorrect patient category, mode, limits or settings are selected or retained across patient/device transitions. 

Application architecture and operating context 

Consider the gas source and blending system, inspiratory/expiratory valves, flow and pressure sensors, patient circuit, humidifier and filters, controller, display, alarm generation, battery and mains power, oxygen supply, accessories, communications, service software and external monitoring. State whether the device is intended for critical care, home use, emergency transport, non-invasive support or another defined environment. 

A useful architecture view should show primary energy/material/data paths, control and monitoring paths, alarms, protective functions, user interactions, external interfaces, maintenance/service modes and reasonably foreseeable single faults. Document assumptions about accessories, environmental conditions and external systems; these assumptions become part of the verification scope and product information. 

Applicable standards and boundaries 

• IEC 60601-2-12: particular requirements for basic safety and essential performance of critical-care ventilators; verify whether the intended device and setting fall within its scope. 

• IEC 60601-2-80 or IEC 60601-2-79 / IEC 60601-2-81 may be relevant to particular respiratory-support device categories; select by intended use and current standard scope. 

• IEC 60601-1: general medical electrical equipment requirements. 

• ISO 14971: risk management. 

• IEC 62304: medical-device software lifecycle processes. 

• IEC 60601-1-8: alarm systems, where applicable. 

• IEC 62366-1: usability engineering. 

• ISO 80601-2-13 and other particular standards may be relevant depending on anaesthetic or respiratory equipment type; confirm exact scope. 

• ISO 13485: quality management systems. 

Applicability note: this is a screening list, not a declaration that every listed standard applies to every product. Confirm the current edition, amendments, national adoption, device classification, intended purpose, product-specific standard scope and target-market requirements before finalising the compliance matrix. Regulatory authorization or formal conformity assessment is distinct from engineering gap assessment. 

Application safety lifecycle 

1. Intended use and system definition: document users, patient population, clinical environment, interfaces, modes, accessories and exclusions. 
2. Hazard analysis and risk estimation: identify hazards, foreseeable sequences of events, hazardous situations and harms; document assumptions and risk acceptability criteria. 
3. Risk control and safety requirements: choose inherently safe design, protective measures and information for safety; derive measurable, traceable requirements. 
4. Architecture and implementation: allocate requirements to subsystems, identify dependencies and common-cause risks, and control software/hardware/configuration baselines. 
5. Verification and validation planning: define methods, fixtures, worst-case conditions, acceptance criteria, usability/clinical evidence needs and test independence. 
6. Integration and system validation: verify risk controls in the integrated device and validate intended use with representative users and environments. 
7. Release, production and post-market: maintain traceability, change impact, supplier controls, service instructions, complaint trending and periodic risk review. 

Hazards, failure scenarios and safety objectives 

The scenarios below are illustrative engineering examples, not a completed project risk analysis, a clinical recommendation, a regulatory determination or a quantitative risk estimate. Severity, probability, risk acceptability and required performance must be established for the specific device and intended use. 

ID	Illustrative hazardous scenario	Potential harm / consequence	Example engineering objective
H-01	Loss or interruption of ventilation	Hypoxia or other serious patient harm	Detect and manage disconnection, power loss, gas-supply faults and internal failures within justified limits.
H-02	Excessive or inadequate pressure/volume	Barotrauma, inadequate ventilation or related injury	Specify monitored variables, control limits, accuracy, protective behaviour and fault responses.
H-03	Incorrect delivered oxygen concentration	Inadequate or excessive oxygen delivery	Define gas-source assumptions, monitoring, sensor fault response and alarms where applicable.
H-04	Hazardous condition not alarmed	Delayed clinical intervention	Verify alarm detection, annunciation, prioritisation, persistence and recovery across operating modes.
H-05	Unexpected mode or setting after restart	Inappropriate respiratory support	Control state retention, default values, configuration, patient transitions and restart behaviour.

 

Safety requirements, architecture and implementation 

Define essential performance and its limits for each intended mode and patient category. Specify pressure/flow/volume control and measurement ranges, accuracy, startup and transition behaviour, circuit disconnection/leak/obstruction detection, gas-supply monitoring, alarm thresholds and response times, alarm priority and muting rules, power-failure behaviour, battery reserve, sensor plausibility, self-test, fault logging and service/configuration controls. Requirements must be derived from risk management and the applicable particular standard; avoid assuming that one ventilator category’s requirements apply to another. 

Use bidirectional traceability from hazards to risk controls, system/subsystem requirements, implementation, verification results and residual-risk conclusions. Requirements should be unambiguous, testable, configuration-controlled and linked to their source. Where a requirement relies on an external standard, cite the exact clause and edition in the controlled compliance matrix rather than relying on a general statement in the blog. 

Verification, validation and safety evidence 

Plan verification using calibrated flow, pressure, volume and oxygen-concentration measurement where relevant. Cover each declared mode and operating boundary; patient-circuit and accessory variants; leaks, disconnections and obstructions; supply pressure variation; sensor faults and drift; alarm latency and annunciation; mains-to-battery transitions; battery aging assumptions; EMC and environmental conditions; condensation-related cases where relevant; software stress and reset; and usability validation. Test worst-case interactions and single faults selected by risk analysis. Document equipment calibration, test fixtures, configurations, software versions, acceptance criteria and residual anomalies. 

A practical evidence set normally includes the risk-management plan and report, architecture and interface descriptions, requirements and traceability, software lifecycle records where applicable, verification protocols/results, usability engineering records, calibration and test-equipment details, deviations and resolutions, configuration baselines, supplier evidence, and justification for residual risks. The required package depends on device class, intended use, market and conformity-assessment route. 

Common pitfalls and how to detect them 

Pitfall	Recommended prevention / detection
Using one test mode as a proxy for all modes	Trace requirements and test coverage to each mode, patient category, accessory and intended environment.
Testing alarms only as isolated functions	Verify end-to-end detection, processing, annunciation, priority, persistence and clinician-facing interface.
Ignoring patient circuit and accessory variability	Include specified circuit lengths, filters, humidifiers, interfaces and foreseeable combinations.
Treating battery status as a simple percentage	Validate reserve estimates, aging assumptions, switchover and low-power fault behaviour.
Confusing device performance with clinical outcome	Engineering verification supports claims but does not replace required clinical evaluation or regulatory evidence.
Applying a particular standard by name alone	Check scope, edition, amendments, intended setting and national deviations before building the compliance matrix.

 

Relationship to adjacent disciplines 

ISO 14971 structures risk analysis and residual-risk evaluation; software lifecycle processes control embedded logic and alarms; usability engineering examines setup, mode selection and alarm response; cybersecurity protects connected devices and service interfaces; reliability and maintainability inform uptime and service assumptions; clinical evaluation and post-market surveillance examine real-world performance. These workstreams should share traceable hazards and evidence.

• IEC 60601-2-12 — Critical-care ventilators; verify current edition and scope. 

• IEC 60601-1 — Medical electrical equipment: general requirements. 

• IEC 60601-1-8 — Alarm systems for medical electrical equipment. 

• ISO 14971:2019 — Medical-device risk management; verify current status. 

• IEC 62304 — Medical-device software lifecycle processes; verify current status. 

• IEC 62366-1 — Usability engineering for medical devices. 

• ISO 13485 — Medical-device quality management systems. 

• Applicable respiratory-support particular standards (e.g., relevant parts of IEC 60601-2 and ISO 80601 series); select based on device scope. 

Currency note — Draft prepared 29 October 2026. Before publication or project use, recheck standards catalogue status, edition, amendments, national adoption and regulatory guidance for each target market. This article is engineering information, not clinical advice, a declaration of conformity, or a substitute for the manufacturer’s risk-management and regulatory processes. 

• Confirm technical reviewer and regulatory reviewer approval. 

• Verify standards editions, scopes, clauses and jurisdiction-specific requirements. 

• Confirm internal links resolve to live VerveTronics pages and use the agreed keyword map. 

• Create original architecture visual and check alt text for accessibility. 

• Ensure claims are evidence-based and do not imply guaranteed compliance, certification or regulatory approval. 

• Check metadata, canonical URL, title/H1 alignment, visible FAQ content, references and final proofreading. 

VerveTronics can assist with medical electrical safety engineering, risk-file and architecture reviews, standards applicability matrices, embedded software assurance, fault-injection planning and verification/validation strategy for respiratory-support products. The first step is to define the device category, care setting, intended patient population, ventilation modes, gas interfaces and target markets. 

Suggested CTA: Request a medical-device safety engineering or standards applicability review.

• Is IEC 60601-2-12 relevant to every ventilator? No. It specifically addresses critical-care ventilators within its scope. Other respiratory-support categories may use different particular standards. 
• Does a successful alarm test prove essential performance? No. Alarm tests are only one part of evidence. The system’s defined essential performance, control accuracy, fault response and usability must also be assessed. 
• Can a ventilator be assessed without defining the patient circuit? A meaningful assessment needs the intended circuits and accessories because they can materially affect flow, pressure, resistance, leak detection and alarm behaviour.