Do ISO 13485's Production Controls apply to SaMD?

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.

Watch the Video:

Listen now:

Love this episode? Leave a review on iTunes!

Have suggestions or topics you’d like to hear about? Email us at podcast@greenlight.guru.

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).

Top takeaways from this episode

1. 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.
2. 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.
3. 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).
4. 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).
5. 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: Connect with Etienne
• 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.

Memorable quotes from this episode

"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

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.

Transcript

Etienne Nichols: Welcome back to the Global Medical Device Podcast. My name is Etienne Nichols and today I am going to we're going to be talking about software as a medical device, but specifically about production controls because software is changing everything in MedTech and the rules that we've relied on for decades, they weren't necessarily built with apps in mind that update weekly or cloud based devices that evolve in real time.

So today we're going to dig into the production side of ISIL 1345 or for software as a medical device where the gray area lives. Hopefully. That's always my favorite place to play, where teams stumble and how to actually stay compliant without killing that innovation.

If you've ever wondered what really happens behind the scenes, hopefully this episode is for you. And today to talk about this is Adnan Ashfak, founder of Simply Medica. He spent over 25 years in quality, and I always get the years mixed up, so you're going to have to correct me, but he's been working on regulatory validation work across startups, global MedTech companies. He's been in the trenches implementing ISO 1345, writing CE technical files, validating software as a medical device under IEC 62304 and remediating FDA design history files. Basically, if there's a gray area in MedTech compliance, he's seen it, he's lived it, he's worked it.

So today he's here to share what really works, what usually trips people up and how to navigate the tricky world of software in medical devices. But I, you know, I could put pontificate about a lot of different things, but good to have you to, to get today with us.

Adan, how are you doing?

Adnan Ashfaq: No, fantastic. Yeah. Once again, thanks very much Etienne for having me on the, the podcast. It's always a complete pleasure.

Etienne Nichols: Absolutely. Well, I always appreciate you willing to share your experience and, and, and your expertise really.

So, I mean, I don't know how, where you want to begin necessarily if you want to just dive in. Maybe we want to talk a little bit of ISO 1345 and the typical approach or, or the expectation and then we can kind of navigate or kind of move over into what that means for software.

Adnan Ashfaq: Sure, yeah. I mean usually, I mean the time and space that we have is never enough to talk about the subject because that's really going to the weeds of things with us.

So, I mean, if you look at historically, I mean, ISO 13485 hasn't actually been around for very long. If we actually think about regulations, really, even in Europe, the medical device development and the amendments came through from the FDA originally. And then in 1993 we developed in Europe the medical device directives. And in 2017, since then we've had the much-debated medical device regulations.

And over the course of that time, we've had ISO 9001, which was aligned 1345, which was aligned with ISO 9001 from 2003. And then we've had the revision in 2016.

And then more recently we've been told that ISO1345 will not be revised in 2026, which is a typical, typical period of after 10 years an ISO standard would get reviewed for revision.

So having said that, I think it's quite timely to have a look at and look at the application of ISO1345 with medical device software in mind. And the reason why I'm particularly interested in that, as you know, Etienne, from my background, I come from a manufacturing background with physical medical devices.

That's where I started off. And in the last 10 years I've been delving a lot more into medical device software.

And then as an engineer, we tend to look at things very technically and how can you apply something from one set of standards to another where typically the ISO 13485 doesn't distinguish between hardware and software?

Right.

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?

That's where I'm going with this podcast and discussion.

Etienne Nichols: Yeah. Okay, great. I love it. And you know, it is interesting because like you said, it doesn't distinguish between software and mechanical or hardware. But there's a lot of, there's, there's nearly always some kind of, I don't know, analogy you can take.

And I'm just thinking from my mechanical engineering background how if you wanted to learn electrical science, you apply the easy-to-understand plumbing technology. You know, you said water flows this way.

Same thing with voltage and so on. So. But it's a similar situation, I think. And so hopefully we can come up with some illustrations that make sense to the audience.

But let's talk about the clauses that you want to jump into. Where do you want to start? There?

Adnan Ashfaq: Yeah, so I'M going to start, I'm kind of going to move straight into clause 7.5, but then I'm also going to come back to the other clause as well. Because clause 7.5 is really where it starts to get a bit kind of muddy for many startups, specifically, not just startups, but even those that are developing medical device software. How do you apply clause 7.5, production and service provision, where we're looking at the core clauses for production framework and then you're looking at the process validation, e.g. clause 7.5.6, traceability, 7.5.9, customer property, 7.5.10 and then 7.5.11 preservation of property, production preservation. So then when we're looking at those clauses, we do have to apply them there. So, some companies try to think that they're non-applicable clauses. So, they may be not applicable because we don't have hardware. But the fact and reality is, let's look at this and unpack this a little bit.

Because when we start to have a look at the production framework, we have to apply those clauses.

Building the processes and looking at integration, looking at comprehensive test protocols, what we have to do. So, thinking of it almost like a pipeline that we've got virtually when we think about a production environment, you think a factory with physical machines, a physical space, an infrastructure, and you know, those processes that you might think that is going to be manufacturing physical hardware.

Now when we look at those clauses, we have to have a look at clause 7.5 and we have to look at it in a virtual space.

So, what does that mean? You almost have to think of this as a virtual manufacturing space.

And if we think about when you're building software and real examples of that, you have to think about the controlled environment that you're going to actually produce the software. So that's where you get into the terminology from EN 62304. You look at the software item, the software system and the software unit, right?

So, you start off with the software item and then you go down to the software system and then the software unit, which a software unit is the lowest denominator or the lowest component lines.

Etienne Nichols: Of code, maybe the code.

Adnan Ashfaq: But then you have to have a look at, for example, let's take GitHub or GitLab or some of the software environments where you are developing. There may be open-source software where you're actually using to develop the software that you're designing.

And then you're going to use then building blocks and you will then bring in different software.

This is where we get into soup. So, the software of unknown provenance, you start bringing those building blocks in and also then it starts getting interesting because those building blocks that you're bringing in also have to be validated as well.

So, you've got the environment which, the space that you're producing, the medical device software in which it could be the open-source software.

And then you're starting to use those building blocks. You've got to think of that almost as a production framework.

And we also have to think of this in terms of the soup items, those software of unknown provenance, which are then being brought in as your supplier verification. So also, we're looking at supplier evaluation here and you're applying clause 7.4, purchasing processes, and you're applying that to the software of unknown providence. Because really what you're doing is you're purchasing some of those building blocks, quote unquote, from off the shelf items, but you've not got any validation. You need to make sure that there's a, there's quality assurance built into those building blocks before you start to actually design and code your own software within that, within that space.

So, you're almost thinking of this in virtual terms, where you had that production framework and you're thinking about how do you verify those soup items? So, there's a verification, and this is where clause 7.4 comes in with the purchasing process, where you've got to then look at the verification of those building blocks, those soup items.

What do you need to do in terms of. Because most of these items are going to be from AWS or Microsoft or some of those platforms which are, you're not going to get a supplier audit, for example, done, you're going to have to look at some certification that gives you the quality assurance that you need to have in mind to make sure that the code that you're going to build on top of that will be done with confidence.

And that's where we're going with it. Because in production terms, when you look at hardware, that's what you're doing, the same thing, you're manufacturing your own medical device in a production space which has already had validated equipment, the infrastructure has been validated, the shop floor and the space, the clean room of the environment that's being manufactured, all of those physical specifics would be validated. Right?

And that's the way ISO 13485, it's written almost as if you're thinking about the hardware, the physical medical devices. Now we have to apply that, and we have to be a bit creative, how we're going to apply those same clauses to, into that medical device software. And this is how we're applying it, because we have to think about the medical device software, which is being written, the software code, the processes. And so, we also have to write protocols, we have to write a master validation plan.

And more recently, FDA for example, has come out with the CAC, the Computer Software Assurance Guidance, which replaces the old GHTF process Validation Guidance document.

And actually, just earlier on this week, I was looking at that, just in line with this discussion is how does that complement things?

Because in the past, I mean, I've had situations where we've done validation in companies that I've worked, and we've validated for software and we've used GAMP. So, some people will be familiar with GAMP.

Now GAMP originally came from the pharmaceutical industry, then worked its way into the medical device industry and was really looking at software systems, computer software systems. And you've also then got to apply 21 CFR part 11 for electronic records and signature.

So that framework that exists really tries to underlie an impact assessment and a risk assessment that you're applying to the software items that you're about to validate.

Now, in the FDA terms, this never really existed. So when I've had an audit done in the past from FDA auditors, they're saying, don't use GAMP, use FDA guidance document if it's being sold in the US specifically, if you've got FDA 510 or five submissions in the US then you should be using guidance documents from the FDA.

Now I think this new document that's come out in September bridges that gap because it then produces some of that impact assessment.

In essence, when I looked over it, it was looking at high risk and low risk software items which you're using for validation off your own software. So, if you stay with me, I know this can be a little bit confusing, but if you stay with the conversation that we're still in the production environment where we're still trying to make sure that we've got confidence in that virtual space where we're then writing this software code within this work environment which we're building these building blocks.

So, we have to make sure that we've got the confidence in all of that. So, we're applying, applying the whole system and the framework. We've got automated pipelines, we need to write those protocols, we need to have that validation plan, we need to do a risk assessment. So, if we're not validating some of those items. What's the rationale that we're not validating them?

It may be because there's nothing that you can validate. You might be doing some verification. It might be because the software itself is an iterative process in itself.

We don't use a waterfall diagram with a lot of software. And again, if you look at ISO 134485, clause 7.3, when it goes into the whole design and development, it's also very much focused on a waterfall approach.

And when we apply that to medical device software, we're really looking at an agile process where it's iterative. So, there's also standards for that, guidance documents like AMI TIR 45 for looking at agile processes.

So, we have to apply a lot of ISO 13485 in those terms into medical device software.

So even things like clauses like 7.5.8, when we're looking at identification, traceability.

Right. So, in hardware that's quite easy to apply because that's the mindset that many of us have come from. But then when you come into software code, you've then got to look at the identification and traceability of the software to the user requirements.

You've got to look at design specification. Software requirement specifications is a specific requirement from EN 62304. And EN 62304 is for those people that aren't familiar with that. That is the medical device software standard that you have to follow.

You have to look at the CLASS safety classifications, class A, B and C and look at the risks involved and then you go through all of those items for validation and it's.

Etienne Nichols: Yeah, it has a really good visual of the V model, of system subsystem requirements and so on. Two things real quick, I don't want to interrupt you necessarily, but GAMP, because some people might not be familiar with that acronym.

Good Automated Manufacturing Process. I think the latest is GAMPS. That's all I've ever heard as far as the. Yeah, it's been. If it is the latest, it's been the latest for a while.

But anyway, gam5 and then the other thing I'll mention, I just wanted to, before we get too far down the road, when we look at 7.5 production and service provisions in ISO3045, are all of them applicable? And maybe we can talk through some that maybe aren't applicable if, if any. And, and, and, but I don't want to slow you down too, if you had another point to make there.

Adnan Ashfaq: No, I mean we can have a look at that. I mean what, what I also like, like to do is when you look at.

Definitely. I mean there's, there's lots of the clauses in, in 1345 within clause 7.5 that won't be applicable. Anything to do with stabilization, for example. Right.

Etienne Nichols: So, cleanliness of product. Yeah, yeah.

Adnan Ashfaq: So those are kind of pretty obvious ones unless you're looking at software in the medical device.

So, you could actually have an active implantable, which has to be sterile.

So, it's not the software part that you're applying, but it's the physical part again which is sterile. Then clause 7.5, 0.5, for example, particular requirements for sterile medical devices and 7.5.7 might come into play for sterilization or sterile barriers.

So those would typically be non-applications for non-applicable clauses for medical device software because there's nothing there to sterilize.

Now the other thing you've also got is installation can come into effect because you might physically install software, even you go ahead.

Yeah. Cloud systems. We also have to make sure that the cloud systems also have a validated environment.

Etienne Nichols: Yeah, I was just thinking about, for example Greenlight Guru or Ultralight, whichever one you were to use from our EQMS platform. There's an installation qualification that we expect you to go through and it's a cloud-based platform, so.

Yeah, that makes sense.

Adnan Ashfaq: Yeah. So, one of the things that we also want to be clear of is not to confuse EQMS validation with medical device.

Right.

So, the software, the medical device.

Etienne Nichols: Yeah, I'm glad you caught that. That's a good point. As soon as the words came out of my mouth like, well, that's muddying the water.

Adnan Ashfaq: Yeah, no, but I'm going to come on to that as well because when I was thinking about this, I'm also thinking about clause 4.1.6 and that's the software validation. So, what you're talking about here is more clause 4.1.6 where an EQMS has to have validation.

So, the IQ needs to be validated. But I'm glad you brought that up because even the soup items that we were talking about earlier on, they can be considered to be part of clause 4.1.6 where you have to make sure that you've established that master validation plan.

So, it's clause 7.5.6 when we talked about the validation of the process.

But it also can be impacted from clause 4.1.6 because we also have to have a look at, for example, the intended use of the SEWP Items we have to look at the validation activities, revalidation, and we have to look at risk assessment. So, 4.1.6 does actually come into effect for that.

But then the other clauses, which are also interesting. Clause 4.2.3 Medical Device Requirements so what do you do here for medical device file requirements? Right. So where typically ISO 13485 will list out, I can't remember, it's A, B, C, D, E, F, G, it lists out the contents of the medical device file. It will say things like labeling instructions, specifications and all these types of things and bill of materials.

Right. So, what do you do then? So, in medical device terms, we've also got to think about an E label, for instance.

So very often you'll have an E label.

Sometimes if you go down to the dropdown menu, you might have about us section in the headers. And the about us very often has a version of the software in that version, the versioning control is.

That's considered to be part of your E label. And now you can also have components like UDI for unique device identification. Your number can also be in that E label.

So that's also part of 4.2.3. So we're looking at labeling and E labeling, right. So not just physical, but also the E label part of the software.

Then what's really interesting is also things like system architecture, your specification. So, the SRS, which will be your software requirement specification, will also come under the contents of the medical device file. Clause 4.2.3, data requirements, cybersecurity controls and the SBoM, which is really interesting because that's another topic. So, what is the software, bill of materials, the components, the dependencies, the libraries?

And you have to have the version controls and change history documented for all of that SBoM.

There's some really interesting articles.

I mean, people can Google that on the SBOM, what an SBOM should look like for medical device software.

We don't have enough time to look at it now, but there are some good guidance documents.

Like I mentioned, the FDA have got some good guidance documents. They're AMI guidance documents.

And there's also more recently I've been looking at, I think it's 34971, which looks at how to apply ISO 14971, risk management in AI and machine learning.

So recently I've also been having a look at that as well.

And then the cybersecurity controls, there's a whole list of cybersecurity standards out there which you also have to apply. Now, the responsibility of identifying those standards and guidelines lies with the manufacturer as the legal manufacturer.

You've got to make sure that you have the state of the art identified standards and you're applying them to your device and technology.

Because even with medical device software, there's so many different applications. They could be installed; it might not be installed. It could be cloud, it may be running from a physical machine which is installed in a laboratory or a hospital or a clinic, and it might be just running off cloud. It might be a software as a service SWS, as we call it. And so, the cybersecurity controls, we have to look at interoperability, you've got to look at the threats.

I'm not a cybersecurity expert by any means at all, but there's cybersecurity experts there.

If you look at the FDA guidance, there's a list of nearly 15 documents that you've got to produce for cybersecurity alone.

Right.

And even within that there's risk analysis. So, we do risk analysis according to ISO 4971, which is actually for the device as a whole. We will look at the. You look at the design, and you look at more of the usability because there's no real process risks.

You look at really design risks and you look at the usability risks for medical device software, cybersecurity, because it's got almost a mind of its own. You've really got to look at the whole package of what's required. Now, all of this that we're talking about comes under clause 4.2.3 as part of your medical device file requirements.

So that's looking at clause 4.2.3. As I said in the beginning of this podcast, I'm cherry picking some of those clauses which will apply and some of the ones that will not apply, that we said quite clearly that is, is for hardware only.

And those sterile ones, for example, won't.

Etienne Nichols: Well, quick question.

So, if we talk about the production side, I'm curious, for software that updates, maybe continuously, what, what actually counts as production under ISO 1345, what would you say?

Adnan Ashfaq: So, there is, because software has an iterative process. What you need to have a look at is any bugs and patches that need to be fixed, that basically need to be ironed out, that might have. There may be some glitches, there might be revision history that's coming out, new versions that are coming out. And you've also got to then look at the change history.

So, the design, if there's a specific design change which is changing the design. So, I Get asked this question a lot. So, in the end I had to actually produce a separate guidance document for what's considered significant change within the actual device software itself.

And what's not considered a change that you can, you know, bypass.

You know, you don't have to have a look at it from the ISO standard or the regulatory standards that this is considered to be a significant change from the production.

You've then got to have a look at from the production clauses. You've got to see if there's any changes that you made with this. Because I call them building blocks, soup items, which I refer to and if there's anything that you changed within that.

Because I had a situation recently where 6 to 12 months elapsed where the last time the software validation was actually done for those soup items.

And then what happened was we realized that during development, the team, the software development team ended up using these other items which were not validated. So, we have to then revise that software validation plan and then make sure that we've got impact assessments for those items.

Again, revise it, look at the impact assessment, look at risk assessment and consider validating those items if they've never been validated. Because effectively what you've done is you've introduced elements within the quote unquote production space which have not been validated.

So that's the thing you've got to be really conscious of. And that's what I would say should be the role of quality and compliance or the QA function. There should be someone that has that role and responsibilities.

Got to make sure that they're on top of that with software developers. And that can, that can be quite tricky. Sometimes the software developers will just run a thousand miles an hour and you know, they'll.

Again, it's. But it's just like in real production, because product, in manufacturing, you know very well, as much as I do, QA have to catch up. And it's the same thing, medical device software.

Etienne Nichols: Yeah, yeah, absolutely. I mean mechanical engineer with access to SolidWorks would probably. And a 3D printer would probably be iterating every day as well. So. Yeah, it makes sense.

Adnan Ashfaq: Yeah, exactly.

Etienne Nichols: Yeah.

So.

And you mentioned agile development a little bit. I'm curious if you feel like agile development. Nice. 1, 3, 4, 5, clash.

What kind of.

And if that's to happen, if that does happen, what kind of invisible compromises are happening or how do you recommend how companies’ approach this?

Adnan Ashfaq: Yeah, so I actually sat in an ISO 13485 audit once for a medical device software and One of the subject matter experts asked us the question, have you done a risk assessment for all of the versions, the version controls? So, while you're developing the device and if you use systems like GitHub, then GitHub should have in it version control and the opportunity to do risk assessments as well. You know, what's the risk for the new revision that's come out? And the thing that's often missing is how it's been documented.

Very often it happens, but very often it's not documented. So how do you document that? That's the key thing you've got to look at is that's from an ISO perspective; that's an open area where there's a possibility for non-conformance.

Etienne Nichols: Yeah. What other parts of the clauses did you want to cherry pick? What other aspects you want to talk about?

Adnan Ashfaq: Yeah, there's still more. There's still more.

Etienne Nichols: Oh yeah.

Adnan Ashfaq: So, clause six, for example, resource management, and we've got infrastructure requirements, so 6.3. So, we're also looking at computing environments, we're looking at data systems, we're looking at security safeguards, do we have reliable resources?

Testing environments, the production hosting platforms. That's what we've really been discussing up until now, disaster recovery capabilities. We've got to look at that as well. So that's the infrastructure part of it. So, we look at clause 6.3.

We've got to look at also compliant data storage and management systems, backup procedures, version control, access logging encryption to protect the sensitive healthcare information.

Right. So, we've got to.

That's another area which is often not really understood.

Clause 6.4, Work Environment and contamination control.

This is a bit out there. Right. So, I'm going to stretch the imagination a little bit because the work environment, as I've already mentioned, we've been talking about the testing environment, production hosting platforms, but we've also got to look at the. For example, the workstations. If you've got workstations that you're working on, are they safe? If you've got robust data protection, you've got to have that encryption and access controls for your workstations as well.

Looking at teams of engineers that might be working on these environments, data scientists, clinical experts, do you have the necessary access controls for them? That's all part of 6.4.1.

And then when it gets to 6.4.2, this is where you have to push the imagination a little bit further because that's contamination control. So, what's contamination control got to do with medical device software?

So, 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 that.

This is where cybersecurity and those controls come in. And as I said, you know, that's not my field expertise. But you've got to make sure that you've got on board someone that understands how to apply this.

But that's where clause 6.4.2, for example, will come in.

Then I'm going to move on to 7.3.8 design transfer to production.

So then again, we're looking at you've done everything in a test environment.

Now you're moving into production. Because an auditor for ISO 13485, especially when you get to stage two, you've got to have records, and you've got to be able to demonstrate that you went from the test environment to production.

And then how do you then verify or validate that? Because you've also got to then make sure that you have examples of software release.

So, a software release is when you get into like your final release of production.

And this is where the software bill of materials comes in really handy. So that going back to clause 4.2.3, where we talked about that medical device file, if you've got like a software bill of materials, that's in essence, that's a bit like saying, we've done everything now in the stages, we're ready to pass this over to production.

And this is what a package looks like.

In that package, you've got to have your design outputs validated, code train models, data pipelines, configuration and documentation from those development stages into the testing phases. You've got to have the evidence of transferring verification, so all of the elements that you validated. So, the software requirement specification that we talked about, those software unit, when we looked at the individual requirements, they've all been validated.

And then you would also have the software design trace matrix. Right. So, the software design trace matrix is just like your design trace matrix, which you would have to trace through your user requirement specifications, your design inputs, your outputs, and then verifying and validating that in software terms, we've got the same thing. Because EN 62304, I mean, I've got a bundle of about 16 documents which conform to the requirements to 62304.

So as long as you've completed all of them, you've completed the requirements to 62304, requirements of medical device Software. So, you've got to make sure that you've got all of those elements ready for production readiness.

Etienne Nichols: Sixteen documents?

Adnan Ashfaq: Yeah, 16 documents in 16. Those 16 documents. I know some companies do actually bundle them together so there are fewer documents.

But I've tried and tested this, it's been successful to have those individual documents and some of those are the risk analysis.

You've got the SEWP declaration, you've got software design trace matrix, you've got to do software systems testing. So, these are all requirements that 62304 suggests that you have those requirements met.

So, through tried and tested model We've produced those 16 documents that then meet the requirements to 62304.

Etienne Nichols: That's awesome. It makes sense to have standalone documents for things that are going to stand on their own.

I'm curious if there are things or in the production clauses, if those apply when users influence the outcomes, meaning the user is going to use it in such a way that it's going to change what the software does. Any thoughts about that?

Are there any kind of gray areas when it comes to those production controls?

Because in my mind I almost think like, well, that is the production environment almost when it's in the user hands to a certain degree when they're manipulating outcomes. But any thoughts there?

Adnan Ashfaq: Yeah. So very often what happens is I've also worked in situations where software developers might actually bring up a pop up, which could be a disclaimer. Right. So, the disclaimer that comes up informs the user that if you use this software which is customizable beyond its intended purpose, then we're not taking any responsibility for that.

So, this is where it gets into the foreseeable misuse.

So, if you think about risk, you think about risk management, where it gets the foreseeable misuse.

If you've got like a customizable user interface with software, that's where that disclaimer comes in handy. And as I've had this situation with software systems were.

It’s been used for like an online clinical service were, sorry, the term's completely escaped from my mind.

But if you've got a self-diagnosis, right, so people go on to these systems which here in the UK we've got, the NHS National Health Service provides these systems where you can just go in and essentially self-diagnose, right?

So, if it comes with a diagnosis which is not truly what you have, that's going to be some serious implications that then at that point is basically comes from the intended use, what the intended purpose is, if it's used beyond that, then that's, that's where that, that's where that kind of lies with misuse.

Etienne Nichols: That makes sense.

Do you feel? So, I feel like a lot of software companies look at these clauses and they say, ah, they don't really apply to me. You can explain how they do.

And then one of the arguments is, well, we're a software company, we're different and this is going to slow us down. How do you answer that question?

Adnan Ashfaq: So, I've seen in many situations, I've seen non applications to a lot of these clauses and subclauses, but I would argue that especially as we're starting to understand software more in the space of artificial intelligence and now machine learning, these things are becoming much more challenging and even auditors are starting to become more experienced with the field and they're asking more questions. So, they're asking for more evidence, you know, how can something be non-applicable where there still is a possibility and you have to prove, you know, is guilty until proven innocent, you know, so it's the theory that you've got to be able to make sure that you can evidence that it is indeed not a non-application.

Some of those ones are quite obvious. But other ones, like I mentioned installation, I mean servicing, on the other hand, because installation and service often go together, you often find that those who put a non-application with installation very often don't have anything to service either.

So, while we've already discussed that it's possible to install software, but is it possible to service software?

So, there's also an argument that you can also, if there's bug fixes and security patches that could be considered to be servicing.

Etienne Nichols: Yeah, that makes sense.

Adnan Ashfaq: Yeah, typically that would be again, as I've said, many of the clients that I've worked with, we've chosen to put a non-application again 7.5.5.4. But I think as we're starting to get smarter with medical device software, I think this is going to.

Some of these other clauses which we previously omitted might start coming into effect and more auditors may start challenging the.

Etienne Nichols: There's a couple that I can think of.

I can use my imagination. As you were saying, I don't know if you mentioned customer property 7.5.10 or preservation of product 7.5.11 or if there are others you want to cover.

Any commentary there?

Adnan Ashfaq: Yeah, I didn't get it yet. I was going to get some point.

Etienne Nichols: Okay, I'm getting ahead of myself. Yeah, go ahead.

Adnan Ashfaq: You are, indeed, Nolan, because I understand we're short on time. But 7.5.10 again, customer property, that's patient data. You've got confidential information.

In some cases, I've had some software where data has been anonymized, so you don't actually have the patient data. So, if it's anonymized, there's an argument that you don't have customer property.

But if it's not anonymized and it's clear that you're using patient data, then that's clearly confidential information. You've then got to apply HIPAA and GDPR for example for contractual confidential information. So then cyber security elements will definitely come into customer property. 7.5.10, 5.11 Preservation of product is also another interesting one because you've also then got to demonstrate that you've got preservation again of the data.

If customer property is effective, then preservation of product most likely will also be effective, you know, so you've also got to make, you've got to demonstrate that you've got protective measures that you're preserving that data. So that's where that comes into effect.

The other one which is interesting is clause 8.2 when you get to monitoring and measurement because post market surveillance also comes into this, right? So, I'm going back to EN 62304 requires problem reporting and problem resolution.

It's one of the things that's required that if you've got and that's where continuous improvement and feedback comes in.

So, where ISO 1.3, 45 talks about feedback and complaints for medical device software you've got problem reporting and problem resolution is basically the equivalent of feedback and complaints.

But you've then got to have a very specific requirement. So, the package of documents that I mentioned were the 16 documents, one of them would be problem resolution and problem reporting.

So, in your complaints database, however you manage to do that, you've got to have behavior patterns of performance monitoring for problem resolution and complaints and feedback. You've got to have some method that you are taking feedback in a proactive way.

So, you've got to make sure that that comes into effect.

So, 8.2 think about monitoring and measurement, post market surveillance and monitoring.

Then also another one which might be slightly unusual is control of non-conforming product, right?

So, we've also got to have looking at how it's possible to apply, you've got to have some level of protocol which you're looking at defective code, right? You might have invalid data, you might have security patches that you've got to look at and justify Deviations, correction of defects, how do you deal with all of that? That is where you've got control of non-conforming product and then rework.

I mean again, that's another one that's usually omitted. Very often medical device software will not have rework post-delivery control.

So those are the main ones. So, the key takeaways that I would kind of sum up with is make sure that you're looking at ISO 1.345 holistically and don't dismiss some of the clauses lightly because there's more and more scrutiny that's coming forward with the auditors understanding AI and machine learning.

And there's a hell of a lot more guidance documents that are coming out both from the FDA and here in Europe also to understand the challenges that medical device software is presenting.

And there's more risk averse solutions. And this is why the recent computer software guidance document that came up.

Etienne Nichols: Okay, so we covered a lot of ground talking about ISO 1345, all the different clauses as they apply to what seems like hardware, but how they actually also apply to software as a medical device.

If you could give one piece of advice or if you could speak to those software as a medical device companies, as they're approaching or thinking about these different clauses, what's the advice you would give them?

Adnan Ashfaq: Yeah, that's a great question. Thanks, Etienne.

So very often as a quality regulatory consultant, I understand the regulations very well. I'm not a software developer. So very often I have to work in partnership as a team with software developers so that they can understand and so I can guide them through the regulations and what the ISO standards mean so that we can work through this together.

Because very often I'm trying to understand.

The application of the medical device software. I mean, typically I've worked a lot in the mental healthcare space, cardiovascular, diabetes, software.

It's a growing sector; there's masses of challenges. The software code can be really, really complex.

It's very important to get the right team members on board at an early stage to make sure that you've got people that understand the regulations, understand the ISO standards, how to apply with the team members.

Because very often when I'm working with startups, it's usually software developers that engineers, they understand code, they're experts in code and they've got no clue about the regulations and the expectations from the medical device world.

And as you and I know, that's a very heavily regulated world that we're in with medical device. And we've always got to think about patient safety, think about risk management, thinking about patient risk, and those are the things that we're always thinking about. So, when ISO1345 is onboarded, just like any medical device, try to embrace it as early as possible because it only starts to get more complicated further down the line.

And medical device software is no different.

As I said, you've got to make sure you've got the right team members, and you've got the right mix of skills to make sure things work smoothly.

Etienne Nichols: Yeah, I think that's really good advice. Especially, you know, each one of those different people, like you said, having those team members, they're going to look at it through a different lens and that way they can just focus solely on the regulatory, focus solely on the product development and then have that conversation.

Yeah, yeah, yeah.

Adnan Ashfaq: No, absolutely, yeah. So, it is very much about teamwork.

So, yeah, it's an interesting space. And as more guidelines and regulations unfold, I'm sure we'll start to get more involved in this. More and more.

Etienne Nichols: Yeah. Always changing. And I think, yeah, we're seeing a lot more of this. So great. Thank you so much, Adnan. I really appreciate you sharing your expertise on this. Those you've been listening really appreciate you hanging in there with us and we will see you all next time.

Everybody take care.

Thanks for tuning in to the Global Medical Device Podcast. If you found value in today's conversation, please take a moment to rate, review and subscribe on your favorite podcast platform. If you've got thoughts or questions, we'd love to hear from you.

Email us at podcast@greenlight.guru.

Stay connected. For more insights into the future of MedTech innovation. And if you're ready to take your product development to the next level. Visit us at www.greenlight.guru, until next time, keep innovating and improving the quality of life.

About the Global Medical Device Podcast:

The Global Medical Device Podcast powered by Greenlight Guru is where today's brightest minds in the medical device industry go to get their most useful and actionable insider knowledge, direct from some of the world's leading medical device experts and companies.

Like this episode? Subscribe today on iTunes or Spotify.