This episode tackles the complex challenge of applying the hardware-centric clauses of ISO 13485 to Software as a Medical Device (SaMD). Adnan Ashfaq, founder of Simply Medica, joins Etienne Nichols to dissect how traditional standards intended for physical manufacturing must be creatively interpreted for the virtual world of software development, where apps update weekly and cloud-based systems evolve in real-time. The conversation zeroes in on the often-muddy areas of production and service provision (Clause 7.5), emphasizing that these clauses are far from non-applicable, requiring a "virtual manufacturing space" mindset.

A significant focus is placed on the Software of Unknown Provenance (SOUP), treating these building blocks as purchased components that require robust supplier evaluation and validation, bridging Clause 7.5 (production) with Clause 7.4 (purchasing). The discussion extends to crucial concepts like the Software Bill of Materials (SBoM), the complexity of Agile vs. Waterfall approaches within the standard's framework, and the essential role of the new FDA Computer Software Assurance (CSA) guidance in risk assessment.

Beyond production, the experts explore the application of resource management (Clause 6), specifically addressing infrastructure, contamination control (malware/ransomware), and the critical need for a well-documented Design Transfer to Production (Clause 7.3.8) evidenced by a complete software release package, including all 62304 requirements. The episode provides actionable insights for quality and compliance professionals struggling to maintain speed and innovation while strictly adhering to regulatory requirements.

Key Timestamps

• 01:45 - The changing landscape: Why traditional MedTech rules struggle with modern software updates.
• 03:50 - Historical context of ISO 13485 and its non-distinction between hardware/software.
• 05:05 - Starting Point: Clause 7.5 (Production and Service Provision) and the "Virtual Manufacturing Space" concept.
• 06:20 - Unpacking Software of Unknown Provenance (SOUP) and its link to Clause 7.4 (Purchasing).
• 08:35 - The necessity of validating the development environment (GitHub/GitLab) and building blocks.
• 11:10 - Applying Clause 4.1.6 (Software Validation) to SOUP items and master validation plans.
• 12:20 - Applicable vs. Non-Applicable Clauses: Sterilization/Cleanliness vs. Installation.
• 13:55 - Clause 4.2.3 (Medical Device File) for SaMD: E-labels, UDI, System Architecture, and SBoM.
• 16:30 - Cybersecurity controls and the manufacturer's responsibility for identifying state-of-the-art standards.
• 17:35 - Defining "Production" for continuously updating software and managing significant vs. non-significant changes.
• 20:15 - Clash of Standards: Agile development, ISO 13485, and the missing documentation for version control risk assessment.
• 21:30 - Clause 6.3 & 6.4 (Resource & Work Environment): Looking at data security, access controls, and contamination (malware/ransomware).
• 24:45 - Clause 7.3.8 (Design Transfer to Production): The need for a formal software release package and the importance of the Software Design Trace Matrix.
• 26:00 - The 16 essential documents needed to meet IEC 62304 requirements.
• 27:10 - Production controls when the user influences the outcome (customizable features, disclaimers).

Quotes

"So my starting point really in this conversation is to cherry pick some of those clauses from ISO 13485, which are more akin to production. And then how do we then unpack that and apply it with medical device software in mind?" — Adnan Ashfaq

"You've got to look at data corruption, you've got to look at unauthorized code, you've got to look at version controlling malware or ransomware, you've got to look at that as well. That's all part of [contamination control, Clause 6.4.2]." — Adnan Ashfaq

Takeaways

• Adopt a "Virtual Manufacturing Space" Mindset: Treat your development environment (e.g., source control systems like GitHub/GitLab, compilers, cloud platforms) as a production floor that requires the same level of validation and control as a physical cleanroom or factory floor, satisfying ISO 13485 Clause 7.5.
• Validate SOUP as Purchased Products: Any Software of Unknown Provenance (SOUP) or open-source components must be treated as "purchased product" under Clause 7.4, requiring documented supplier verification, impact assessment, and validation (or documented rationale for non-validation) before integration into your SaMD.
• Contamination Control is Cybersecurity: ISO 13485 Clause 6.4.2, Contamination Control, must be applied to the digital sphere. This includes safeguards against malware, ransomware, unauthorized code, and data corruption, emphasizing the non-negotiable need for robust cybersecurity controls in your Quality Management System (QMS).
• Formalize the Software Bill of Materials (SBoM): The SBoM, detailing all software components, libraries, dependencies, and their version controls, is a key deliverable under Clause 4.2.3 (Medical Device File), acting as the digital equivalent of a Bill of Materials for Design Transfer to Production (Clause 7.3.8).
• Bridge Agile with Documentation: When using Agile development, ensure every iteration, bug fix, or patch includes a documented risk assessment (connecting to ISO 14971) and change history to satisfy ISO 13485’s traceability and control requirements, preventing potential non-conformances in audit.

References

• Etienne Nichols' LinkedIn: linkedin.com/in/etiennenichols
• ISO 13485:2016 (specifically Clauses 7.5, 7.4, 4.2.3, 6.3, 6.4, 7.3.8)
• IEC 62304 (Medical device software – Software life cycle processes)
• FDA Computer Software Assurance (CSA) Guidance: The new guidance replacing older process validation guidance, focusing on a risk-based approach (High Risk vs. Low Risk) for validating software tools.
• AAMI TIR 45 (Guidance on the use of agile practices in the development of medical device software)

MedTech 101 Section

Software of Unknown Provenance (SOUP)

SOUP refers to software components that have been developed for purposes other than being part of the medical device, and for which the developer did not use a medical device quality management system (QMS) process. In simple terms, it's off-the-shelf software (like an open-source library, a commercial operating system, or a third-party module) that you integrate into your SaMD.

Analogy: If you are building a custom, high-end car (your medical device), the engine block (the SaMD code) is custom-made. However, you decide to use commercially available tires, a standard battery, and a third-party GPS system (the SOUP items). While convenient, you can't be 100% sure how those other developers built them. To use them in your regulated medical product, you must perform your own testing and validation (verification) on the SOUP components to ensure they work reliably and safely within your device's specific intended use, treating them as if you purchased them from an outside supplier under Clause 7.4.

Feedback Call-to-Action

We thrive on your expertise and insights. If you have questions about applying ISO 13485 to your specific SaMD project, or if you'd like to suggest a topic for a future deep-dive, please send us an email. We read every message and offer personalized responses to help you navigate the complexities of MedTech compliance.

Contact us at: podcast@greenlight.guru

Sponsors

This episode discussing the critical balance of innovation and compliance in SaMD is brought to you by Greenlight Guru. In a world where software updates are weekly, using antiquated paper-based or general-purpose QMS systems is a compliance risk. Greenlight Guru offers MedTech-specific solutions, including a leading QMS platform and an advanced EDC solution, that are designed to handle the complexity of modern device development, like seamless traceability for your Software Bill of Materials and automated audit trails, ensuring you stay compliant with standards like ISO 13485 and IEC 62304.