IEC 62304 Software changes - Minor labeling changes on the GUI

[Myodoll]

I am a software developer at a small startup and we are currently working on developing the software as part of an integrated device. The device is used to collect and analyze patient data in clinical studies. We have had the first version of the software released, and are currently working on changing the spftware for a different indication of use, and the only changes we will be making are minor labeling changes on the GUI. However, we want to keep both versions of software available for future use (so not obsoleting either one of them). For compliance with IEC 62304, shall we start a new set of DHF? Will we need to perform the risk analysis again, or is there a way to justify that there will be no additional risk involved by this change? As we have a very tight timeline we would like to minimize the amount of documentation work to do. Does anyone have any suggestions? Thank you in advance for your help!!

 

[JPHD1]

Without knowing enough about your product and the actual changes, I can only offer brief guidance. This is not legal advice. Please consult an SME who can look into your documentation and processes.

Sounds like you'll have two separate products with different intended uses?

Your documentation should demonstrate you've done your due diligence to ensure each product is safe and effective to use by intended users, in the intended context, for the intended purpose. I assume you've done all that for the previous software. Even if you think the changes to the new software are minor, they need to be looked at in the same holistic way with safety and efficacy in mind. And then documented.

For example, are there any new, previously not considered users? Does the change in the GUI introduce new potential use errors? Or can the incorrect software version be accidentally released to unintended users?

What may be helpful, although not completely equivalent, is to look at what FDA considers important in the light of 510(k) submission for a software change (search for Deciding When to Submit a 510(k) for a Software Change to an Existing Device Guidance for Industry and Food and Drug Administration Staff).

In a nutshell, the analysis goes like this:

1. Is the change made solely to strengthen cybersecurity and does not have any other impact on the software or device?
2. Is the change made solely to return the system into specification of the most recently cleared device?
3. What are the impacts of any changes to risks associated with use of the device and the impacts of any changes to the risk controls for the device?
   • Does the change introduce a new risk or modify an existing risk that could result in significant harm and that is not effectively mitigated in the most recently cleared device?
   • Does the change create or necessitate a new risk control measure or a modification of an existing risk control measure for a hazardous situation that could result in significant harm?
4. Could the change significantly affect clinical functionality or performance specifications that are directly associated with the intended use of the device?

You can see there are quite a few important questions you'll need to be able to answer. How you document your thought process and how you ensure (in production and post-production) your products are safe and effective is up to you.

 

[Tidge]

If you are subject to FDA oversight, allow me to direct you towards a somewhat recent 2019 FDA guidance: Policy for Device Software Functions and Mobile Medical Applications

Without knowing any details beyond what was written, you probably can expand the existing DHF to cover multiple products as a 'family' of devices.
If you do so, you will need to make sure that the elements in a single DHF support each device appropriately (i.e. requirements, specification, V&V, risk analysis). IF certain elements (e.g. risk analysis) get too confusing to keep in a single document, it would be appropriate to disentangle documents as necessary. This could be discrete sections of documents in the DHF, or it could be new documents in a single DHF.

 

[yodon]

shall we start a new set of DHF?

Regarding this question, each product must have a complete DHF, but it can well be a 'virtual folder.' We have clients that have multiple software products all based on, essentially, a core library. There are unique aspects to each product but to compile the complete DHF for any product, the shared information is pulled from the library material. It's just a matter of organization.