• 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 

Unintended beam-on or failure to terminate: Control logic, monitor chamber, beam termination path or interlock fault allows radiation outside the intended conditions. 

Incorrect treatment parameters or patient data: Wrong patient, plan, energy, field, dose, fraction or machine configuration is selected or transferred. 

Positioning and coordinate mismatch: Couch, gantry, collimator, imaging or reference-frame errors create a mismatch between intended and delivered geometry. 

Interlock bypass or unclear service state: Maintenance/service access, bypass controls or mode indication permit unsafe operation or leave protection defeated. 

Data transfer and configuration errors: Version mismatch, corrupted plan, stale calibration or incompatible interfaces change treatment execution. 

Motion collision or mechanical failure: Gantry, couch, patient support or accessory motion creates collision, entrapment or positioning hazards. 

Common-cause and environmental failures: Power, cooling, network, sensor, software or facility conditions affect multiple protective functions. 

Application architecture and operating context 

Define the system boundary across treatment planning and data transfer, record-and-verify interfaces, control console, treatment management software, accelerator or radiation source, beam generation/modulation, dosimetry monitors, gantry/collimator/couch motion, imaging and positioning, door and area interlocks, emergency-off functions, service modes, network interfaces and facility infrastructure. Separate equipment safety from facility radiation protection and clinical treatment protocols while documenting their interfaces. 

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-1: particular requirements for basic safety and essential performance of electron accelerators in the range covered by the standard; confirm the equipment category and scope. 

• IEC 60601-2-11 may apply to gamma beam therapy equipment; other radiotherapy modalities require their own applicable particular standards. 

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

• ISO 14971: medical-device risk management. 

• IEC 62304: software lifecycle processes for medical-device software. 

• IEC 62366-1: usability engineering. 

• IEC 61217: coordinates, movements and scales for radiotherapy equipment, where applicable. 

• IEC 62083: safety requirements for radiotherapy treatment planning systems, where applicable. 

• IEC 62359 and other modality-specific standards may be relevant depending on the equipment; verify current scope. 

• ISO 13485 and applicable radiation protection, facility and national regulatory requirements. 

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	Radiation delivered when not intended	Unintended patient/staff exposure	Define independent beam-enable conditions, interlocks, beam termination and evidence for single-fault behaviour.
H-02	Incorrect dose or treatment field delivered	Patient injury or ineffective treatment	Control treatment data, parameter validation, dose monitoring, calibration and plan-to-delivery traceability.
H-03	Treatment not terminated at the required point	Excess exposure or unintended dose	Verify primary and backup monitoring/termination paths and fault response under defined conditions.
H-04	Patient support or gantry collision	Patient injury or equipment damage	Define motion limits, collision avoidance/detection, emergency stop and recovery procedures.
H-05	Safety interlock defeated or misrepresented	Unsafe exposure or access to hazardous area	Control bypass authority, duration, indication, audit logs and restoration checks.

 

Safety requirements, architecture and implementation 

Specify beam-enable prerequisites, beam termination response, independent dose/beam monitoring, interlock states, door/access interfaces, emergency-off behaviour, service-mode restrictions, bypass governance, treatment-data integrity, plan transfer validation, coordinate and motion accuracy, calibration/configuration control, fault indication, event logging and recovery behaviour. Define acceptance criteria from the applicable standards, risk-management file, equipment specification and regulatory requirements. Do not publish generic dose limits, timing values or interlock architecture as universal requirements; these depend on modality, design and applicable rules. 

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 

Use a risk-based V&V strategy covering beam-on/beam-off control, interlock activation and fault cases, beam termination, monitor-channel faults, parameter and plan transfer, corrupted/incomplete/stale data, coordinate and motion accuracy, collision protection, emergency-off, power interruption, software update and service modes. Use appropriate phantoms, calibrated dosimetry and independent measurement where required. Validate software against representative treatment workflows and configurations; test interfaces end-to-end. Evidence should include test plans, calibrated instruments, traceability, independent review, deviations, configuration baselines and rationale for any simulation-only coverage. 

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
Confusing equipment compliance with clinical safety	Define equipment, facility, workflow and clinical responsibilities, and verify the interfaces between them.
Testing only normal beam delivery	Include unintended activation, termination faults, interlock failures, data corruption, service mode and recovery.
Relying on one software or data-transfer check	Use layered validation, version/configuration controls and end-to-end checks of plan identity and parameters.
Treating bypasses as ordinary maintenance features	Govern authorisation, indication, time limitation, logging, restoration and post-maintenance proof tests.
Using unverified generic dosimetry values	Derive criteria from the exact modality, standard, approved specification and qualified clinical/radiation-safety process.
Insufficient configuration traceability	Record machine configuration, software, treatment planning version, calibration and test setup for every result.

 

Relationship to adjacent disciplines 

ISO 14971 supports risk management; software lifecycle assurance addresses control and treatment-management software; cybersecurity protects treatment data and service access; usability engineering reduces selection and workflow errors; metrology and quality assurance support calibration and dosimetry; facility radiation protection addresses shielding, access control and operational procedures. The responsibilities must be coordinated but not conflated. 

• IEC 60601-2-1 — Medical electron accelerators within the standard’s scope; verify edition and applicability. 

• IEC 60601-2-11 — Gamma beam therapy equipment; verify edition and applicability. 

• IEC 61217 — Radiotherapy equipment: coordinates, movements and scales; verify current status. 

• IEC 62083 — Safety requirements for radiotherapy treatment planning systems; verify current status. 

• ISO 14971 — Medical-device risk management. 

• IEC 62304 — Medical-device software lifecycle processes. 

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

• ISO 13485 and applicable national radiation-protection / medical-device regulations. 

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 support radiotherapy equipment developers with system hazard analysis, safety architecture review, software/hardware requirements traceability, interlock and fault-injection test planning, and standards gap assessments. A scoped engagement should identify the radiation modality, equipment class, treatment workflow, facility interfaces, target jurisdictions and the role of qualified medical physics and radiation-protection specialists. 

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

• Does IEC 60601-2-1 cover all radiotherapy systems? No. It addresses a defined class of electron accelerators. Gamma, brachytherapy, proton and other modalities may require different standards and additional regulatory requirements. 
• Can software verification alone establish radiotherapy safety? No. Safety evidence also depends on hardware, dosimetry, interlocks, motion, data transfer, calibration, facility interfaces and clinical workflow. 
• Are facility radiation protection and device safety the same? They overlap at interfaces but are not identical. Equipment safety, facility shielding/access control and clinical treatment governance each have distinct requirements.