Physical Address
304 North Cardinal St.
Dorchester Center, MA 02124
CAN/CSA C22.2 No. 60601-1-14 (2018) – Programmable Electrical Medical Systems Safety Requirements
Comprehensive Guide to the Canadian Adoption of IEC 60601-1-14 for PEMS
Scope and Application
CAN/CSA C22.2 No. 60601-1-14 (2018) is the Canadian adoption of IEC 60601-1-14:2018, a collateral standard to IEC 60601-1. It specifies general requirements for the basic safety and essential performance of Programmable Electrical Medical Systems (PEMS) and their subsystems. The standard applies to medical electrical equipment or systems that incorporate one or more programmable electronic subsystems (PESS) to achieve their intended function.
This standard covers the entire PEMS life cycle, including design, development, verification, validation, and modification. It is intended for use by manufacturers, regulatory bodies, and testing laboratories involved in the certification of medical devices that rely on software and programmable electronics. Compliance with this collateral standard is required for any medical electrical system containing programmable elements that claim conformity with the CAN/CSA C22.2 No. 60601-1 series.
Note: CAN/CSA C22.2 No. 60601-1-14 (2018) is harmonized with the international IEC edition and is recognized by Health Canada for medical device licensing. Manufacturers should also consider the latest amendments and corrigenda issued by CSA Group.
Technical Requirements for PEMS
General Requirements and Risk Management
The standard establishes a risk management process throughout the PEMS life cycle, aligned with ISO 14971. Manufacturers must identify hazards related to programmable functions (e.g., software faults, timing errors, communication failures) and implement risk control measures. The tolerable risk levels and residual risk evaluation must be documented.
Software Verification and Validation
CAN/CSA C22.2 No. 60601-1-14 requires a structured software development life cycle (SDLC) that includes:
- Software safety classification (determination of software safety class based on the severity of potential harm)
- Traceability from requirements to tests
- Static and dynamic analysis
- Integration testing at the software and system level
- Regression testing after modifications
| Requirement | Description | Reference Clause |
|---|---|---|
| PEMS life cycle | Defines activities from conception to decommissioning, including risk management and configuration control. | 4.2, 4.3 |
| Software safety classification | Software components are classified as Class A, B, or C based on the degree of contribution to a hazardous situation. | 4.4.2 |
| Risk control measures | Effectiveness of risk control measures for programmable functions must be verified and validated. | 4.5 |
| Configuration management | All hardware, software, and documentation items must be uniquely identified and version-controlled. | 5.1 |
| Verification and validation | Comprehensive plan and report for verification of each PEMS requirement and validation of safety and performance. | 5.2, 5.3 |
| Modification and change management | Any change to a PEMS must be subject to a risk assessment and regression testing. | 5.4 |
Hardware-Software Interaction
The standard requires analysis of interactions between hardware and software, especially in safety-critical functions. This includes watchdog timers, memory protection, error detection and correction (EDAC), and communication integrity. The PEMS architecture must ensure that single-point faults do not lead to a loss of safety functions.
Compliance and Testing
Testing Requirements
Manufacturers must perform both software integration testing and system validation testing under normal and single-fault conditions. Testing must cover:
- All software modules and interfaces
- Boundary conditions and corner cases
- Timing and real‑time behaviour
- Resets, power interruptions, and electromagnetic disturbances
Important: For PEMS that implement essential performance, the test evidence must demonstrate that safety functions are not compromised by any software anomaly. This may require fault injection testing (e.g., corrupting data, delaying signals) to verify the system response.
Documentation and Quality System
Compliance with CAN/CSA C22.2 No. 60601-1-14 necessitates a comprehensive PEMS technical documentation file that includes:
- System architecture description
- Software requirements specification
- Software design description
- Verification and validation plans and reports
- Risk management file (including software hazard analysis)
- Configuration management records
The standard is intended to be used in conjunction with CAN/CSA C22.2 No. 60601-1 (General requirements for basic safety and essential performance) and, where applicable, the ISO 13485 quality management system.
Non‑compliance risk: Failure to meet the PEMS life‑cycle requirements may result in a non‑conformity during CSA Group certification or Health Canada audits. Inadequate software risk management can lead to recalls and patient safety incidents.
Implementation Considerations
Adopting a Life‑Cycle Approach
To effectively implement CAN/CSA C22.2 No. 60601-1-14, manufacturers should integrate the PEMS life‑cycle activities into their existing product development processes. Early incorporation of risk management and safety analysis reduces costly redesigns. Use of automated verification tools and continuous integration/continuous testing (CI/CT) pipelines can help maintain traceability and repeatability.
Common Challenges
- Software classification confusion: Determining whether a software component is Class A, B, or C requires careful analysis of the severity of potential harm and the contribution of the software to the hazardous situation. Manufacturers sometimes underestimate the safety significance of a component, leading to insufficient verification effort.
- Legacy systems: Upgrading existing PEMS to comply with the 2018 edition may require significant re‑engineering, especially if the original product was not developed under a structured SDLC.
- Third‑party software: When using commercial off‑the‑shelf (COTS) software components, the manufacturer must still provide evidence that the entire PEMS meets the safety requirements. Reliance on supplier documentation without independent evaluation is rarely sufficient.
Best practice: Engage a CSA‑accredited testing body early in the development process. Conduct pre‑certification gap analyses to identify missing documentation or verification gaps. This approach significantly reduces the time to certification and market access in Canada.
Future Developments
As medical devices increasingly rely on artificial intelligence (AI), machine learning (ML), and cloud connectivity, the principles of CAN/CSA C22.2 No. 60601-1-14 remain relevant, though additional guidance from the IEC 60601‑1 series (e.g., drafts on AI safety) may supplement its requirements. Manufacturers should monitor updates from CSA Group and Health Canada to ensure ongoing compliance.
Q: What is the relationship between CAN/CSA C22.2 No. 60601-1-14 (2018) and IEC 60601-1-14:2018?
A: CAN/CSA C22.2 No. 60601-1-14 (2018) is the identical Canadian adoption of IEC 60601-1-14:2018, with no deviations. It is recognized by Health Canada and is the applicable standard for medical equipment containing programmable electrical subsystems sold in Canada.
A: CAN/CSA C22.2 No. 60601-1-14 (2018) is the identical Canadian adoption of IEC 60601-1-14:2018, with no deviations. It is recognized by Health Canada and is the applicable standard for medical equipment containing programmable electrical subsystems sold in Canada.
Q: Does the standard apply to all software used in a medical device?
A: It applies to software that is part of a programmable electrical medical system (PEMS) as defined in Clause 3 of the standard. Stand‑alone software that does not control an electrical medical system may be subject to other standards (e.g., IEC 62304). However, when software is integrated into a medical electrical system, this collateral standard applies.
A: It applies to software that is part of a programmable electrical medical system (PEMS) as defined in Clause 3 of the standard. Stand‑alone software that does not control an electrical medical system may be subject to other standards (e.g., IEC 62304). However, when software is integrated into a medical electrical system, this collateral standard applies.
Q: What are the main documentation deliverables required for certification?
A: The major deliverables include: PEMS risk management file, software requirements specification, software design description, verification and validation plans/reports, configuration management records, and a summary of the software life cycle. The documentation must demonstrate traceability from hazards to risk controls and from requirements to tests.
A: The major deliverables include: PEMS risk management file, software requirements specification, software design description, verification and validation plans/reports, configuration management records, and a summary of the software life cycle. The documentation must demonstrate traceability from hazards to risk controls and from requirements to tests.
Q: How does the standard address cybersecurity?
A: While the 2018 edition does not include an explicit cybersecurity clause, the risk management process required by the standard covers threats to programmable functions, including malicious data input, communication errors, and unauthorized access. Manufacturers are expected to follow IEC 60601-1-2 (EMC) and IEC 60601-1-8 (alarm systems) for related risks, and should also consider IEC 62304 (software life cycle) and IEC 81001-5-1 (health software security) as complementary standards.
A: While the 2018 edition does not include an explicit cybersecurity clause, the risk management process required by the standard covers threats to programmable functions, including malicious data input, communication errors, and unauthorized access. Manufacturers are expected to follow IEC 60601-1-2 (EMC) and IEC 60601-1-8 (alarm systems) for related risks, and should also consider IEC 62304 (software life cycle) and IEC 81001-5-1 (health software security) as complementary standards.