Medical Device Software Standards (Part 3)

IEC 60601-1 Clause 14 and IEC 62304

IEC 60601-1 Clause 14 and IEC 62304

The software development processes defined in IEC 62304 and IEC 60601-1 Clause 14 follow the V-Model of software development, as illustrated in Figure 6.
In IEC 60601-1 Clause 14, the software system is defined as a sub-requirement under the Programmable Electrical Medical System (PEMS) framework.

During PEMS development, the IEC 62304 standard is applied at the PEMS component level — from defining software requirements, through the assembly of software items, to integration into the overall software system.
This software system then becomes part of the Programmable Electrical Subsystem (PESS).

Therefore, IEC 62304 mainly addresses software verification within the PESS but does not cover full software validation at the system level.

Figure 6 – Software as Part of the V-Model

(Source: ANSI/AAMI/IEC 62304:2006, Medical Device Software—Software Life Cycle Processes)

In Figure 6:

• Green area: Software development process under IEC 62304
• White + Green area: PEMS development process under IEC 60601-1 Clause 14
• Rectangles: Development activities
• Solid arrows: Deliverables (inputs/outputs of each activity)
• Dashed arrows: Deliverables incorporated into the Risk Management File
• Thick arrows (right-facing): Outputs from the software problem resolution process
• Thick arrows (left-facing): Inputs to the software problem resolution process

IEC 62304: Key Clauses

IEC 62304 comprises six major clauses (4–9), as shown in Figure 7 and detailed below.

Figure 7 – IEC 62304 Main Clauses

(Source: ANSI/AAMI/IEC 62304:2006, Medical Device Software—Software Life Cycle Processes)

Clause 4: General Requirements

This clause includes several sub-clauses:

• Clause 4.1 – Quality Management System
  Requires software development to be conducted under a formal quality management system, generally aligned with ISO 13485.
• Clause 4.2 – Risk Management System
  Requires a risk management process for software development, referencing ISO 14971.
• Clause 4.3 – Software Safety Classification
  Defines the classification of software based on safety severity levels:

• Definitions:
  
  • Software System: A complete software entity (or PESS) consisting of multiple software items.
  • Software Item: A discrete unit of software, which may itself contain sub-items.
  • SOUP (Software of Unknown Provenance): Software with unknown development and safety characteristics.
  • Legacy Software: Software with known development and safety characteristics, reused in new systems.

Figure 8 – Software System Structure and Safety Classification

To determine a software system’s safety class:

1. Identify all software components within the system.
2. Assess the severity level of each component.
3. Assign the overall system classification based on the most severe component.

Example:

• If components include Classes C, B, and A → the system is Class C.
• If components include Classes B and A → the system is Class B.
• If all components are Class A → the system is Class A.

For example (see Figure 8):
A software system includes components X and Y, where Y consists of subcomponents W (Class B) and Z (Class C).
→ Component Y is Class C.
→ Even though X is Class A, the overall system becomes Class C due to the most severe classification.

Clause 5: Software Development Process

As shown in Figure 6, this clause describes the step-by-step software development process with the following sub-clauses:

1. Clause 5.1 – Software Development Planning
   Planning the entire software development lifecycle.
2. Clause 5.2 – Software Requirements Analysis
   Defining and analyzing functional and non-functional requirements.
3. Clause 5.3 – Software Architectural Design
   Designing software architecture, identifying software items, SOUP, and legacy software (see Figure 8).
4. Clause 5.4 – Software Detailed Design
   Detailed design of software units.
5. Clause 5.5 – Software Unit Implementation and Verification
   Coding each software item and performing unit-level verification.
6. Clause 5.6 – Software Integration and Integration Testing
   Combining software items and testing their integration (see Figure 9).
7. Clause 5.7 – Software System Testing
   Testing the complete integrated system (Figure 9 – circular area).
8. Clause 5.8 – Software Release
   Preparing, installing, and verifying the software for deployment.

Figure 9 – Levels of Software Testing

Clause 6: Software Maintenance Process

This clause includes:

• 6.1 – Establish Software Maintenance Plan
  Define the post-release maintenance plan.
• 6.2 – Problem and Modification Analysis
  Analyze issues and modifications after system delivery.
• 6.3 – Modification Implementation
  Implement and verify modifications following analysis.

Clause 7: Software Risk Management Process

Includes:

• 7.1 – Analysis of Software Contributing to Hazardous Situations
  Analyze hazards from software items, SOUP, and legacy software.
• 7.2 – Risk Control Measures
  Define and apply mitigation measures.
• 7.3 – Verification of Risk Control Measures
  Verify risk reduction effectiveness.
• 7.4 – Risk Management of Software Changes
  Manage risks arising from software changes.

Note: Clause 7 builds upon Clause 4.2 (Risk Management).

Clause 8: Software Configuration Management Process

Key sub-clauses:

• 8.1 – Configuration Identification
  Identify work products and outputs to be controlled (see Figure 10).
  Examples include design documents, configuration items (CI), and file naming conventions, e.g.:
  
  • F-001-SoftwareDevelopmentPlan → Software Development Plan Form
  • File name: xxx-SoftwareDevelopmentPlan

Control also includes:

• • File storage (electronic folders or physical cabinets)
  • Versioning (see Figure 11 – left)
  • Development path definition (see Figure 11 – right)
• 8.2 – Change Control
  Manage software changes systematically (see Figure 12).
• 8.3 – Configuration Status Accounting
  Track status of configuration items — draft, reviewed, approved, etc.

Figures 10–12: Examples of Configuration and Change Management

• Figure 10 – Example Configuration Item
• Figure 11 – Versioning and Development Path
• Figure 12 – Software Change Process

Clause 9: Software Problem Resolution Process

Includes:

• 9.1 Prepare problem reports
• 9.2 Investigate problems
• 9.3 Advise relevant parties
• 9.4 Use change control process
• 9.5 Maintain records
• 9.6 Analyze problems for trends
• 9.7 Verify software problem resolution
• 9.8 Test documentation contents

An example process is shown in Figure 13 – Software Problem Resolution Process.

After Software Development

Once medical device software development is complete, manufacturers should verify all required evidence items (see Figure 14).
This Evidence List corresponds to the primary and sub-requirements of IEC 62304, and will be submitted to the Testing Laboratory for certification or regulatory approval.

Figure 14 – Example Evidence List

Conclusion

This three-part article series has presented an overview of IEC 62304, the international standard for medical device software life cycle processes.
In the next article, we will continue exploring related standards — particularly IEC 60601-1 Clause 14, which governs safety requirements for programmable electrical medical systems (PEMS).

Stay tuned!

References

1. Roger Pressman (2009). Software Engineering: A Practitioner’s Approach (7th ed.). McGraw-Hill, New York, USA.
2. Ivan Mistrik et al. (2015). Software Quality Assurance: In Large Scale and Complex Software-Intensive Systems (1st ed.). Morgan Kaufmann, San Francisco, USA.
3. Medical Device Software—Software Life Cycle Processes, ANSI/AAMI/IEC 62304, 2006.