Follow Us:

IEC 62304

Home IEC 62304 Consultants
Quick Contact
iec 62304 standard

IEC 62304 Consultants

IEC 62304 consultants at I3CGlobal help medical device manufacturers and SaMD developers navigate the complexities of IEC 62304 standard compliance across all three software safety classes — Class A, Class B, and Class C. Our consultants work directly with your software development team and process owners to explain each clause of IEC 62304:2006, interpret Certification Body (CB) and Notified Body (NB) expectations, and build a compliant software lifecycle from development planning through release and post-market maintenance.

 

Whether you are preparing for an FDA 510(k) submission, EU MDR CE marking, or IVDR technical documentation, our team of consultants bridges the gap between your software engineering team and regulatory requirements by providing ready-to-use procedure templates, SOP drafts, risk management guidance aligned with ISO 14971, and hands-on review of every deliverable from your end

 

We do not just hand over documents; we sit with your process owners, walk them through all 16 IEC 62304 procedures, and ensure they understand what auditors and reviewers expect to see. Our engagement model clearly defines what I3CGlobal delivers as your compliance partner and what your software developers own as the technical execution team, so there are no gaps, no overlaps, and no surprises during a CB or NB audit.

Key Roles of 62304 Consultants

IEC 62304 Consultants play a vital role in guiding organisations through the process of complying with the standard’s requirements and implementing best practices for medical device standard compliance. Here’s a breakdown of their key roles:

IEC 62304 Consultants

Effectively coordinating with consultant team with software developers requires careful planning, clear communication, and a focus on building relationships and trust. By implementing the strategies outlined in this document, organizations can leverage the expertise of consultants to achieve their project goals while ensuring knowledge transfer and long-term sustainability.

 

Remember that flexibility and adaptability are key to success when working with consultant teams. Continuously evaluate and refine your coordination strategies to optimize performance and achieve desired outcomes.

IEC 62304

IEC 62304 Software Classification

IEC 62304 standard establishes a cohesive framework for designing and testing software for medical devices through defined processes, activities, and tasks, ensuring safe usage in patients. The standard categorizes software into three safety classes according to the risk to the patient from a possible software failure

 

  • Class A: No injury or damage to health is possible
  • Class B: Non-serious injury is possible
  • Class C: Death or serious injury is possible

IEC 62304 Specific Requirements

The subsequent 5 chapters of IEC 62304 detail specific requirements and guidelines for the development and proper implementation of medical device software.

Chapter Description
Chapter 5 Software development and planning process including requirements analysis, design, testing, and release processes.
Chapter 6 Software maintenance plan, including the implementation of a maintenance plan and issue analysis procedures.
Chapter 7 Software risk management and identification of hazardous situations, risk control, verification, and risk management procedures following the ISO 14971 standard.
Chapter 8 Software configuration management including change control and configuration status tracking.
Chapter 9 Software problem resolution investigating and reporting on problems, change control processes, trend analysis, and resolution testing and verification.

The FDA encourages the use of recognized consensus standards to show compliance. IEC 62304 standard acknowledged by the FDA for this purpose. Employing 62304 can facilitate the 510k submission process as it offers a comprehensive framework for software development, risk management, and documentation.

IEC 62304 standard

Benefits of Implementing IEC 62304 Standard

Implementing the IEC 62304 standard offers several benefits for software medical device manufacturers (SAMD & SIMD). A few are listed below:

 

  • Compliance with 62304 helps ensure that medical device software is developed with patient safety as a primary consideration. By identifying and mitigating risks throughout the software lifecycle, organizations can minimize the likelihood of software-related errors or malfunctions that could harm patients

 

  • Adhering to 62304 facilitates compliance with regulatory requirements in the European Union, the United States, and other regions where the standard is recognized. This can streamline the regulatory approval process and expedite certifications and approvals faster

 

  • The standard emphasizes the importance of risk management in medical software. By systematically identifying, assessing, and mitigating risks, organizations can proactively address potential hazards and ensure the safety and effectiveness of their final released software

IEC 62304 is a standard that outlines requirements and guidelines for the development of medical device software; however, it does not ask for a certification or no certification body issues certificates.

 

Organizations can demonstrate compliance with IEC 62304 by implementing the standard’s requirements and following its guidelines throughout their software development processes

 

While there is no formal IEC 62304 Standard, organizations can still provide evidence of their adherence to the standard through documentation and audit reports. This can help build confidence in customers, regulatory authorities, and other stakeholders

With the help of IEC 62304 consultants such as I3CGlobal, the developers can identify, prepare, modify, implement, and conduct regular reviews and updates to these procedures to ensure ongoing compliance and effectiveness in managing software development activities.

IEC 62304 Consultants - Detailed Statement of Work

IEC 62304 – Statement of Work
IEC 62304:2006 — Statement of Work
All 16 procedures · Responsibility split: I3CGlobal (Consultant) vs. Software Developer
I3CGlobal
Developer
Shared
Common I3CGlobal responsibility across all 16 procedures Interact with process owners to explain applicable IEC 62304 clauses, interpret CB / NB (Certification Body / Notified Body) requirements, and ensure the team understands what each clause demands in the context of their software safety class and regulatory submission (FDA 510k / EU MDR / IVDR).
NoCl#ProcedureI3CGlobal (Consultant)Software DeveloperLead
📋 Chapter 5 — Software Lifecycle (Development)
15.1
Software Development Planning
Class A+B+C
  • Provide SDP template and guidance
  • Define documentation structure per safety class
  • Review and approve the final SDP
  • Advise on Class C-specific clauses (5.1.4–5.1.11)
  • Author the Software Development Plan
  • Define lifecycle model and project milestones
  • Identify tools, languages, and SOUP dependencies
  • Maintain and update SDP throughout the project
Shared
25.2
Software Requirements Analysis
Class A+B+C
  • Provide SRS template aligned with IEC 62304
  • Facilitate requirements traceability matrix setup
  • Review SRS for regulatory completeness
  • Elicit and document software system requirements
  • Map system-level to software requirements
  • Maintain requirements traceability
Shared
35.3
Software Architectural Design
Class B+C
  • Provide architectural design document template
  • Review architecture for IEC 62304 compliance
  • Advise on SOUP identification and interface spec
  • Design and document software architecture
  • Define software item interfaces and SOUP items
  • Identify risk controls within architecture
  • Verify architecture against requirements
Developer
45.4
Software Detailed Design
Class B+C
  • Provide detailed design document template
  • Review detailed design documentation
  • Refine architecture into unit-level design
  • Define unit interfaces and algorithms
  • Produce class/data flow diagrams (Class C: 5.4.2–5.4.4)
Developer
55.5
Verification of Software Unit
Class A+B+C
  • Define unit verification strategy and acceptance criteria
  • Review unit test reports for completeness
  • Develop and execute unit test cases
  • Perform code reviews and static analysis
  • Document and maintain unit test records
  • Apply coverage criteria for Class B/C (5.5.2–5.5.5)
Developer
65.6
Verification & Testing of Integrated Software
Class B+C
  • Provide integration test plan template
  • Review integration test results
  • Define and execute integration test plan
  • Verify software item interfaces and data flows
  • Document integration test results and anomalies
Developer
75.7.1
Software System Testing
Class B+C
  • Define system test strategy and traceability to requirements
  • Review system test protocol and final report
  • Develop and execute system test cases covering all requirements
  • Document test results and open defects
Shared
85.7.3
Retest After Changes
Class B+C
  • Advise on regression test scope and impact assessment criteria
  • Review retest results and approve closure
  • Retest software system whenever changes occur during testing
  • Document retest scope, results, and pass/fail evidence
  • Update traceability matrix to reflect retested requirements
Developer
95.8
Software Release
Class A+B+C
  • Define release checklist and record template
  • Verify all lifecycle activities are complete pre-release
  • Issue release authorization
  • Compile release documentation and known anomaly list
  • Confirm all test evidence is captured
  • Tag and archive the release build in configuration management
Shared
🔧 Chapter 6 — Software Maintenance
106.1
Establishing Software Maintenance Plan
Class A+B+C
  • Provide maintenance plan template
  • Review maintenance plan for regulatory alignment
  • Establish and document the software maintenance plan
  • Define change evaluation and implementation process
Shared
116.2.1
Feedback
Class A+B+C
  • Define feedback monitoring SOP and escalation criteria
  • Review feedback log and advise on regulatory significance
  • Monitor and record feedback from users and internal sources on released software
  • Categorise and log feedback for analysis and follow-up
Shared
126.2.3 / 6.2.4 / 6.2.5
Analysis, Approval & Communication of Changes
Class A+B+C
  • Define change analysis and approval procedure
  • Advise on regulatory reporting obligations for changes
  • Review change impact assessments
  • Analyse and document change requests and impact
  • Obtain approvals per defined change control process
  • Communicate approved changes to users and regulators
Shared
136.5
Implementation of Approved Modifications
Class A+B+C
  • Ensure modifications follow the defined development process
  • Review updated documentation post-modification
  • Implement approved modifications using development or maintenance lifecycle processes
  • Update all affected documentation and test records
Developer
⚠️ Chapter 7 — Risk Management
147
Risk Management Process
Class A+B+C
  • Lead risk management process per ISO 14971
  • Provide risk analysis, evaluation, and control SOP templates
  • Review risk file for completeness and regulatory adequacy
  • Advise on software-specific hazardous situations
  • Identify software failure modes and hazardous situations
  • Implement risk control measures in software design
  • Verify effectiveness of risk controls through testing
  • Maintain and update the risk management file
Shared
🗂️ Chapter 8 — Configuration Management
158
Configuration Management
Class A+B+C
  • Define configuration management procedure and document templates
  • Establish version control naming conventions and baselines
  • Audit configuration records for compliance
  • Implement version control for all software items and documents
  • Maintain configuration status accounting records
  • Control changes through the defined change control process
I3CGlobal
🐛 Chapter 9 — Problem Resolution
169
Software Problem Resolution
Class A+B+C
  • Define problem resolution SOP and trending methodology
  • Review problem reports and trend analysis outputs
  • Advise on reportable problem thresholds
  • Record, investigate, and analyse all software problems
  • Implement and verify problem fixes
  • Track trends and escalate recurring issues
Shared

Frequently Asked Questions

What is medical device software?

Any software associated with a medical device or Invitro diagnostic device regardless of software in a medical device, software as a medical device, firmware, or embedded software is called medical software.

What Types of Software are Included?

Software used for medical device design, development, production, installation, and support is covered under the IEC 62304 standard. This includes the supporting software used in production and quality control in addition to the software that works directly with the patient or performs a medical function.

What is the timeline for ISO 62304 Implementation?

 ISO 62304 Implementation generally, it takes 3-4 months.

Is IEC 62304 mandatory for an FDA 510(k) submission?

While IEC 62304 is not mandatory for FDA 510(k) submission, it is a recognized consensus standard that must be followed in fulfilling FDA requirements for software as a medical device (SAMD).