Unreleased software for troubleshooting and clinical use

alimary15

Involved In Discussions
#1
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:
Elsmar Forum Sponsor

yodon

Staff member
Super Moderator
#2
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
#3
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
#4
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
#5
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

Staff member
Super Moderator
#6
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
#7
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
 
Thread starter Similar threads Forum Replies Date
B Using Unreleased Documents & Process Maps for Internal Audit purposes ISO 9000, ISO 9001, and ISO 9004 Quality Management Systems Standards 12
J ECO (Engineering Change Order) Control for Unreleased Products Document Control Systems, Procedures, Forms and Templates 3
V Internal Audit Software IATF 16949 - Automotive Quality Systems Standard 5
Watchcat New Draft Guidance on Content of Premarket Submissions for Software Device "Functions" Other US Medical Device Regulations 2
Watchcat Software validation vs design V&V? Other US Medical Device Regulations 27
M Initial Importer/Distributor and Software Validation IEC 62304 - Medical Device Software Life Cycle Processes 1
F Configurator for a power unit - Software or other solution? Manufacturing and Related Processes 0
D Test Management Software Software Quality Assurance 1
E ISO 13485 software validation ISO 13485:2016 - Medical Device Quality Management Systems 7
D Tracking software versions used with instruments ISO 13485:2016 - Medical Device Quality Management Systems 0
dgrainger Informational MHRA's Software and AI as a Medical Device Change Programme UK Medical Device Regulations 0
S Do you follow your QMS for non-device software features? Medical Information Technology, Medical Software and Health Informatics 4
J Can we register non-device clinical decision support software under draft guidance? Other US Medical Device Regulations 5
I Software (SaMD) mobile application verification testing: objective evidence Medical Information Technology, Medical Software and Health Informatics 2
J EU equivalent to Clinical Decision Support Software EU Medical Device Regulations 3
Y ISO 13485:2015 Software Validation IQ/OQ/PQ ISO 13485:2016 - Medical Device Quality Management Systems 13
S Recommended software to send Quality scorecards to suppliers (external providers) Supplier Quality Assurance and other Supplier Issues 3
J Software as a Medical Device - SaMD IEC 62304 - Medical Device Software Life Cycle Processes 3
BeaBea QMS/ Training Management Software Service Industry Specific Topics 4
shimonv Working with a software developer who is not setup for IEC 62304 IEC 62304 - Medical Device Software Life Cycle Processes 9
R Debug mode in software/device validation IEC 62304 - Medical Device Software Life Cycle Processes 2
Q Gage calibration / tracking software General Measurement Device and Calibration Topics 5
M Software verification and validation AS9100 AS9100, IAQG, NADCAP and Aerospace related Standards and Requirements 4
Y RT-qPCR Software result EU Medical Device Regulations 0
B A.I. diagnostic software is considered as medical device in FDA? US Food and Drug Administration (FDA) 6
F WANTED Senior Software engineer Career and Occupation Discussions 2
P Blood establishment computer software EU classification EU Medical Device Regulations 0
S Examples of FDA acceptable Software Design Specification (SDS) Medical Device and FDA Regulations and Standards News 6
D Integrated Management System Software Quality Manager and Management Related Issues 2
B Sampling strategies/techniques for software QA Software Quality Assurance 3
K MDCG-2020-3 (about the software of UI) EU Medical Device Regulations 3
D PFMEA Software search IATF 16949 - Automotive Quality Systems Standard 7
C MDR software classification EU Medical Device Regulations 12
H Class II a vs "software safety class A" IEC 62304 - Medical Device Software Life Cycle Processes 4
Z Software for design control ISO 13485:2016 - Medical Device Quality Management Systems 5
V Medical Device Literature Translation Software ISO 13485:2016 - Medical Device Quality Management Systems 1
D FDA Guidance on Computer Software Assurance versus 21 CFR Part 11 21 CFR Part 820 - US FDA Quality System Regulations (QSR) 2
P Software verification and validation procedure IEC 62304 - Medical Device Software Life Cycle Processes 6
Aymaneh UDI-PI Software CE Marking (Conformité Européene) / CB Scheme 0
Q Software as a medical device vs software not sold as medical device: local regulations for sale? EU Medical Device Regulations 4
Y Software updates considered servicing (7.5.4) ISO 13485:2016 - Medical Device Quality Management Systems 4
S How to perform verification of the Statistical Analysis Software? Qualification and Validation (including 21 CFR Part 11) 7
I Document Control Software Document Control Systems, Procedures, Forms and Templates 2
E Software maintenance Process Software maintenance Process to IEC 6204? IEC 62304 - Medical Device Software Life Cycle Processes 3
L Micro-Vu InSpec Software Program Qualification and Validation (including 21 CFR Part 11) 6
A For software change - New Channel of interoperability CE Marking (Conformité Européene) / CB Scheme 5
T IVDR Medical device software CE Marking (Conformité Européene) / CB Scheme 8
N ISO 13485 7.3.9 Change control in medical device software ISO 13485:2016 - Medical Device Quality Management Systems 6
C SharePoint Contract Management Software General Information Resources 0
gramps What do you think about automated QA testing For software app industry? Misc. Quality Assurance and Business Systems Related Topics 5

Similar threads

Top Bottom