Unreleased software for troubleshooting and clinical use

alimary15

Involved In Discussions
Good afternoon,

I have a dilemma and i would like some of you to help me.

Let's say an healthcare facility has a machine with a software that is used for clinical treatment. This software version is released and after some time a problem is found about the software that requires the machine to be serviced.
The service engineer go on site and install a new unreleased version of the same software (beta software) with some parameters changed for troubleshooting purposes.Please note this beta software is not released but it might be just a test version not to be used for clinical use.

My questions are: - mIs it possible to install at costumer site an unreleased version of software? Even if only for the purpose of troubleshooting, Wouldn't this mean that an unreleased medical device software is put into the market thus breaking FDA Regulation?

How would any of you address such particular scenario?
Thanks so much
 
Last edited:

yodon

Leader
Super Moderator
I would expect that you will have to install the 'troubleshooting' software (I'll call it debug software from here on) just to enable the service tech to get the equipment operating properly?

I would take extraordinary efforts to ensure that the debug software CANNOT be used on / for / with patients (or whatever the applicable intended use is). Maybe you can password protect it, have some timeout feature, have a lockout feature after some time (e.g., a day), maybe a screen displaying "NOT FOR CLINICAL USE," or even disabling the clinical use features (just allow the service tech to do whatever diagnostics are required). I would take any and all measures available to prevent the debug software from being used in the clinical application.

After the service tech completes the work, the debug version must be removed and either replaced with the old software release a new software release (or nothing installed and the equipment rendered unusable).

I would definitely collect records confirming that the tech followed the correct procedure and gets positive confirmation that the correct software is loaded at the end (supplementing the already-required service record information). You may even want to get the customer to sign off the service record indicating it's been demonstrated that the debug software has been removed and the correct software load is installed and operational.

Indeed, it's a risk but probably necessary. Define the best measures to eliminate the wrong outcome (users having access to the debug version) and you should be in a defensible position.
 

mihzago

Trusted Information Resource
I'll second yodon's response and emphasize that if the system is to be used again by clinicians, the troubleshooting software must be removed, and the old software re-installed after which full testing (for example production, or post-test, whatever you call it, i.e. the same test protocol used after assembly prior to the device being shipped) executed.
 

alimary15

Involved In Discussions
I would expect that you will have to install the 'troubleshooting' software (I'll call it debug software from here on) just to enable the service tech to get the equipment operating properly?

I would take extraordinary efforts to ensure that the debug software CANNOT be used on / for / with patients (or whatever the applicable intended use is). Maybe you can password protect it, have some timeout feature, have a lockout feature after some time (e.g., a day), maybe a screen displaying "NOT FOR CLINICAL USE," or even disabling the clinical use features (just allow the service tech to do whatever diagnostics are required). I would take any and all measures available to prevent the debug software from being used in the clinical application.

After the service tech completes the work, the debug version must be removed and either replaced with the old software release a new software release (or nothing installed and the equipment rendered unusable).

I would definitely collect records confirming that the tech followed the correct procedure and gets positive confirmation that the correct software is loaded at the end (supplementing the already-required service record information). You may even want to get the customer to sign off the service record indicating it's been demonstrated that the debug software has been removed and the correct software load is installed and operational.

Indeed, it's a risk but probably necessary. Define the best measures to eliminate the wrong outcome (users having access to the debug version) and you should be in a defensible position.

Thank you so much for the help.

Do you have any standard / guideline that describes all the above? I want to make sure that it is possible to allow beta testing/ debug software installation during servicing and what are the requirements in testing and provinding records that we must fullfill to show compliance. Can any one help me to identify such requirements? thank you
 
Last edited:

alimary15

Involved In Discussions
I'll second yodon's response and emphasize that if the system is to be used again by clinicians, the troubleshooting software must be removed, and the old software re-installed after which full testing (for example production, or post-test, whatever you call it, i.e. the same test protocol used after assembly prior to the device being shipped) executed.

Thank you for the explanation.

Could you please indicate me any regulatory reference/ standard / guideline that describes the above process?

I would like to show proof that it is allowed to install beta/debug software for troubleshooting during servicing and know the exact requirements we should fullfill in order to still demonstrate compliance.

Thank you
 

yodon

Leader
Super Moderator
I don't know of any guidance that would address this specific case. Should the debug software get used in clinical practice, there's certainly plenty of regulation that you would violate.

Sometimes we need to let common sense be the guidance. :) The goal of the FDA is to protect the public. They want to ensure that anything used on the public is safe and effective. When you establish controls that prevent your debug software from being used in practice on / for the end users, you're doing what's expected.
 

mihzago

Trusted Information Resource
If you live in the FDA world, then there are several regulations directly or indirectly specifying general requirement related to servicing:
- 21 CFR 820.72 Inspection, Measuring and Test equipment (what and how you test your device during manufacturing applies to servicing too)
- 820.80 Receiving, in-process, and finished device acceptance (again, your methods for verifying that the device after you modified it still meets at least the requirements you specified during production)
- 820.86 Acceptance status
-820.200 Servicing (this one does not say whole lot other than you should have an established process for servicing)

To summarize, there are no specific requirements describing what you can or cannot do when a device is in your control (e.g. what software you instal on it for troubleshooting or what equipment you use to fix it); How you perform service is up to you, but you must ensure that the "fixed/modified" device meets the same requirements you specified for the product before it initially leaves your facility (think of DMR, device master record and DHR, device history record).
Quick example, a device that is approved for release has a DMR that specifies all parts and components in it, including software versions, etc. A DHR will contain a reference to that list, as well as what acceptance activities it underwent prior to release. If you subsequently modify this during service (for example, the released software was ver 1.0.1, but your serviced device has software ver 1.0.2) then you're out of compliance.
Unless of course the new version was approved for use.

If you can get your hands on the "Medical Device Quality Systems Manual: A Small Entity Compliance Guide", you will find some additional guidance. I think FDA pulled this guidance, but I'm sure there are plenty of copies floating everywhere.

hope this helps
 
Top Bottom