Can GAMP Be Used in Medical Device Companies?

Introduction

As a consultant, I have provided consultation services to numerous medical device companies. During these engagements, I occasionally receive questions such as, “Is this software Category 4?” This type of question raises significant concerns.

Category classification is a methodology from GAMP (Good Automated Manufacturing Practice), which serves as a voluntary standard primarily for the pharmaceutical industry. GAMP was originally developed to ensure quality assurance in automated processes within pharmaceutical manufacturing facilities. While category classification is effective for classifying software installed in “equipment and facilities” used in pharmaceutical manufacturing, it is fundamentally not suitable for software development in medical device companies.

Importantly, no regulatory requirements for medical device companies reference or mandate the use of GAMP.

The origins of why GAMP began to be used in medical device companies remain unclear.

Regulatory Requirements for Medical Device Software in Japan

In Japan, regulatory requirements for software design control in medical device companies do exist, contrary to some misconceptions. The primary regulatory framework includes:

Quality Management System (QMS) Ministerial Ordinance

The “Ministerial Ordinance on Standards for Manufacturing Control and Quality Control for Medical Devices and In Vitro Diagnostic Reagents” (QMS省令) establishes comprehensive quality management requirements, including software design and development controls. This ordinance requires medical device manufacturers to implement appropriate design controls for software incorporated into medical devices.

JIS T 2304 (IEC 62304 Japanese Standard)

Japan has adopted IEC 62304 as JIS T 2304, which specifically addresses medical device software lifecycle processes. This standard is recognized and referenced within the Japanese regulatory framework, providing detailed guidance on software development and maintenance for medical devices.

Pharmaceutical and Medical Device Act (PMDA)

The law formerly known as the Pharmaceutical Affairs Law was amended in 2013 and renamed the “Act on Securing Quality, Efficacy and Safety of Products Including Pharmaceuticals and Medical Devices” (commonly abbreviated as “Yakujihou” or “Pharmaceutical and Medical Device Act”). This law was fully implemented on November 25, 2014, and it strengthened quality assurance requirements for software embedded in medical devices and stand-alone software as a medical device (SaMD).

Historical Context: The Therac-25 Incident

Between 1985 and 1987, the U.S. FDA documented a tragic incident involving a radiation therapy device called Therac-25. Software defects in this device resulted in the deaths of six patients due to radiation overdoses. This incident became a watershed moment in medical device software regulation and served as the primary catalyst for developing comprehensive software validation guidance.

FDA’s General Principles of Software Validation (GPSV)

In response to the Therac-25 incident and growing concerns about software safety in medical devices, the FDA developed the General Principles of Software Validation (GPSV). The timeline for this guidance was:

• Draft Guidance: Published in June 1997
• Final Guidance: Published in January 2002

GPSV describes the principles for validating software used in the design, development, and manufacturing of medical devices. It serves as a guide for both the medical device industry and FDA staff regarding computerized system validation (CSV). The document provides detailed specifications for the verification processes that should be implemented throughout software development.

Scope of GPSV Application

GPSV applies to the following types of software:

1. Software used as a component, part, or accessory of a medical device
   1. Examples: Embedded software in diagnostic equipment, control software in implantable devices
2. Software that is itself a medical device
   1. Examples: Blood bank software, clinical decision support software, diagnostic algorithms
3. Software used in the production of medical devices
   1. Examples: Programmable Logic Controllers (PLCs) in manufacturing equipment, automated quality control systems
4. Software used in implementation of the medical device manufacturer’s quality system
   1. Examples: Software for recording device history records (DHR), maintenance tracking software, complaint management systems, electronic quality management systems (eQMS)

International Standard: IEC 62304

In Europe, Canada, Australia, and many other regions, medical device manufacturers must comply with IEC 62304 “Medical device software – Software life cycle processes” for both software embedded in medical devices and stand-alone software medical devices.

IEC 62304 Overview

IEC 62304 was first published in 2006 and provides a comprehensive framework for medical device software development. The standard defines:

• Software development lifecycle processes
• Software maintenance processes
• Software risk management activities integrated with ISO 14971
• Software safety classification (Class A, B, C)
• Configuration management and problem resolution

IEC 62304 Amendment 1 (2015)

In 2015, Amendment 1 to IEC 62304 was published, introducing important updates:

• Enhanced integration with ISO 14971:2007 (medical device risk management)
• Clarification of software safety classification criteria
• Updated guidance on software of unknown provenance (SOUP)/off-the-shelf (OTS) software
• Strengthened requirements for cybersecurity considerations

JIS T 2304

Japan has adopted IEC 62304 as JIS T 2304, making it part of the Japanese regulatory framework. Medical device manufacturers in Japan are expected to comply with this standard when developing medical device software.

Current International Regulatory Landscape

IMDRF Guidance Documents

The International Medical Device Regulators Forum (IMDRF) has published several guidance documents that are increasingly influential in global medical device software regulation:

1. Software as a Medical Device (SaMD): Key Definitions (2013)
   1. Establishes common terminology for SaMD globally
2. SaMD: Clinical Evaluation (2017)
   1. Provides guidance on clinical evaluation appropriate to SaMD
3. SaMD: Quality Management System (2015)
   1. Describes quality management system principles specific to SaMD
4. SaMD: Possible Framework for Risk Categorization (2014)
   1. Proposes risk-based categorization for SaMD

FDA Software Guidance Evolution

The FDA has continued to update its software guidance:

• Content of Premarket Submissions for Management of Cybersecurity in Medical Devices (2014, updated 2018, postmarket guidance 2016)
• Software as a Medical Device (SAMD): Clinical Evaluation (2017)
• Computer Software Assurance for Production and Quality System Software (2022) – This represents a paradigm shift toward assurance-based approaches

European Medical Device Regulation (MDR)

The EU Medical Device Regulation (MDR 2017/745), which became fully applicable in May 2021, includes specific requirements for software:

• Software intended for medical purposes is explicitly defined as a medical device
• Enhanced clinical evaluation requirements
• Stricter post-market surveillance obligations
• Updated common specifications and harmonized standards references

Cybersecurity Requirements

Modern medical device software regulation increasingly emphasizes cybersecurity:

• FDA Premarket Cybersecurity Guidance (2018, draft update 2022)
• FDA Postmarket Cybersecurity Guidance (2016)
• IEC 81001-5-1: Health software and health IT systems safety, effectiveness and security (published 2021)
• MDCG 2019-16: EU guidance on cybersecurity for medical devices

Why GAMP Is Not Appropriate for Medical Device Software

Fundamental Differences in Purpose

GAMP was designed for pharmaceutical manufacturing systems and focuses on:

• Validation of automated manufacturing processes: Ensuring that automated equipment in pharmaceutical production consistently produces products meeting predetermined specifications
• Infrastructure software: Database systems, operating systems, and other infrastructure components used in pharmaceutical manufacturing
• Category-based approach: GAMP 5 categorizes software (Categories 1-5) based on complexity and configurability, which is suitable for manufacturing and quality systems but not for medical device software development

Medical Device Software Characteristics

Medical device software differs fundamentally from pharmaceutical manufacturing systems:

1. Direct patient impact: Medical device software often directly affects patient diagnosis, treatment, or monitoring
2. Real-time requirements: Many medical devices require real-time or near-real-time software performance
3. Safety classification: Medical device software must be classified based on potential harm to patients (IEC 62304 Classes A, B, C)
4. Risk management integration: Software development must be tightly integrated with risk management per ISO 14971
5. Clinical validation: Medical device software often requires clinical validation to demonstrate safety and effectiveness

Regulatory Recognition

As noted earlier, no regulatory authority for medical devices specifically references or requires GAMP. Instead, regulators reference:

• IEC 62304 for software lifecycle processes
• FDA GPSV for validation principles
• ISO 14971 for risk management
• IEC 62366 for usability engineering
• ISO 13485 for quality management systems

Comparison Table: GAMP vs. Medical Device Software Standards

Aspect	GAMP 5	IEC 62304 + FDA GPSV
Primary Industry	Pharmaceutical manufacturing	Medical device manufacturing
Regulatory Basis	Voluntary industry standard (ISPE)	Internationally recognized standard / FDA guidance
Focus	Validation of computerized systems in pharmaceutical manufacturing	Software lifecycle processes for medical devices
Classification Approach	Category-based (1-5) by configurability and complexity	Safety class-based (A, B, C) by potential harm
Risk Management	General consideration	Mandatory integration with ISO 14971
Software Type	Manufacturing systems, laboratory systems, infrastructure	Embedded device software, SaMD, manufacturing software
Lifecycle Model	V-Model typically	Flexible lifecycle models (waterfall, iterative, agile)
Regulatory Recognition	Pharmaceutical regulators (FDA, EMA for pharma)	Medical device regulators globally (FDA, EU, Health Canada, TGA, PMDA)
Clinical Evidence	Not required	Required for medical device software
Usability Engineering	Limited guidance	Required per IEC 62366
Cybersecurity	General IT security	Specific medical device cybersecurity requirements

Software Development Approach for Medical Device Companies

Medical device companies must adopt a comprehensive approach that integrates multiple standards and regulatory requirements:

Core Standards Framework

1. IEC 62304: Medical device software lifecycle processes
   1. Defines the required software development and maintenance processes
   1. Specifies documentation requirements
   1. Establishes safety classification methodology
2. ISO 14971: Application of risk management to medical devices
   1. Risk analysis throughout software development
   1. Risk evaluation and control measures
   1. Risk management throughout product lifecycle
3. IEC 62366-1: Application of usability engineering to medical devices
   1. User interface design and evaluation
   1. Formative and summative usability testing
   1. Use-related risk analysis
4. ISO 13485: Medical devices — Quality management systems
   1. Overarching quality management system requirements
   1. Design and development controls
   1. Post-market surveillance

Regional Regulatory Requirements

United States:

• FDA GPSV principles
• FDA software guidance documents (premarket and postmarket)
• FDA cybersecurity guidance
• FDA Software as a Medical Device guidance

Europe:

• Compliance with Medical Device Regulation (MDR 2017/745) or In Vitro Diagnostic Regulation (IVDR 2017/746)
• Harmonized standards including IEC 62304
• MDCG guidance documents
• CE marking requirements

Japan:

• Compliance with Pharmaceutical and Medical Device Act
• JIS T 2304 (IEC 62304)
• PMDA guidance documents
• QMS Ministerial Ordinance

Canada:

• Compliance with Medical Devices Regulations (SOR/98-282)
• Recognition of IEC 62304 and ISO 13485
• Health Canada software guidance

Australia:

• Compliance with Therapeutic Goods Act 1989
• TGA medical device software guidance
• Recognition of IEC 62304 and ISO 13485

Modern Development Approaches

Medical device software development has evolved to accommodate modern software engineering practices:

1. Agile Development: IEC 62304 allows for iterative and incremental development when properly controlled
2. Software as a Medical Device (SaMD): Specific guidance for standalone software medical devices
3. Artificial Intelligence/Machine Learning: Emerging guidance for AI/ML-based medical devices (FDA’s AI/ML Software as a Medical Device Action Plan, EU AI Act considerations)
4. DevOps and Continuous Software Validation: Modern approaches to continuous integration/continuous deployment with appropriate controls
5. Cloud-Based Solutions: Considerations for software delivered via cloud platforms
6. Mobile Medical Applications: Specific guidance for mobile apps as medical devices

Practical Implementation Guidance

Software Safety Classification

Under IEC 62304, software must be classified based on the potential for the software to contribute to a hazardous situation:

• 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

This classification drives the rigor of documentation, testing, and review activities required.

Software Development Lifecycle Activities

Regardless of the specific lifecycle model chosen, medical device software development must address:

1. Software Development Planning
   1. Lifecycle model selection and justification
   1. Standards and methods to be applied
   1. Resource and schedule planning
   1. Risk management planning
2. Software Requirements Analysis
   1. Functional and performance requirements
   1. User interface requirements
   1. Safety requirements derived from risk analysis
   1. Traceability to system requirements
3. Software Architectural Design
   1. Major software components and their interfaces
   1. SOUP/OTS software identification and evaluation
   1. Segregation by safety class
4. Software Detailed Design
   1. Detailed design of software units
   1. Design verification planning
5. Software Unit Implementation and Verification
   1. Coding standards adherence
   1. Unit testing
6. Software Integration and Integration Testing
   1. Integration strategy
   1. Integration testing per test plan
7. Software System Testing
   1. Verification of software requirements
   1. Testing in representative use environment
   1. Regression testing
8. Software Release
   1. Known residual anomalies evaluation
   1. Released version documentation

Essential Documentation

Medical device software development requires comprehensive documentation:

• Software Development Plan
• Software Requirements Specification
• Software Design Specification (Architecture and Detailed Design)
• Software Verification and Validation Plan and Reports
• Risk Management File (software-related risks)
• Traceability matrices
• Software Configuration Management Plan
• Software Problem Resolution procedures
• Software Release documentation

Conclusion

Medical device companies must recognize that GAMP is not an appropriate framework for medical device software development and validation. While GAMP serves the pharmaceutical manufacturing industry well, it does not align with the specific regulatory requirements and standards established for medical devices.

To successfully develop medical device software and enter global markets, companies must:

1. Comply with IEC 62304 (or JIS T 2304 in Japan) for software lifecycle processes
2. Follow FDA GPSV principles for software validation
3. Integrate ISO 14971 for risk management throughout the software lifecycle
4. Implement IEC 62366 for usability engineering
5. Maintain ISO 13485 compliant quality management systems
6. Address cybersecurity requirements per current regulatory guidance
7. Stay current with evolving regulatory requirements for emerging technologies such as AI/ML, SaMD, and cloud-based solutions

The regulatory landscape for medical device software continues to evolve, with increasing emphasis on cybersecurity, post-market surveillance, and adaptive approaches for innovative technologies. Medical device manufacturers must maintain awareness of these developments and adapt their software development practices accordingly.

By adhering to internationally recognized standards and regulatory guidance specific to medical devices, rather than pharmaceutical manufacturing standards like GAMP, medical device companies can ensure patient safety, regulatory compliance, and successful global market access.

References and Further Reading

Standards:

• IEC 62304:2006 + AMD1:2015 – Medical device software – Software life cycle processes
• ISO 14971:2019 – Medical devices — Application of risk management to medical devices
• IEC 62366-1:2015 – Medical devices — Part 1: Application of usability engineering to medical devices
• ISO 13485:2016 – Medical devices — Quality management systems

FDA Guidance Documents:

• General Principles of Software Validation (2002)
• Content of Premarket Submissions for Software Contained in Medical Devices (2005)
• Software as a Medical Device (SAMD): Clinical Evaluation (2017)
• Computer Software Assurance for Production and Quality System Software (2022)

International Guidance:

• IMDRF Software as a Medical Device (SaMD) Working Group documents
• GHTF Study Group 2 documents (predecessor to IMDRF)

Regional Resources:

• EU Medical Device Coordination Group (MDCG) guidance documents
• Japan PMDA guidance documents
• Health Canada medical device software guidance
• Australia TGA software guidance

Note: This article reflects the regulatory landscape and best practices as of early 2025. Readers should verify current requirements with relevant regulatory authorities, as regulations and guidance continue to evolve, particularly in areas such as artificial intelligence, machine learning, and cybersecurity.