SBS - The best value in QMS software

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
Z Software for design control ISO 13485:2016 - Medical Device Quality Management Systems 3
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) 3
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 4
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
V Software as medical device (SaMD) replicated for multiple clients through APIs IEC 62304 - Medical Device Software Life Cycle Processes 5
U API Spec Q1 - 5.6.1.2 C (3) - Design software Oil and Gas Industry Standards and Regulations 3
B Complaint Records - Accessing records on Easy Track Software Records and Data - Quality, Legal and Other Evidence 3
GreatNate Master Control QMS software Quality Tools, Improvement and Analysis 0
GreatNate Anyone using the Intellect QMS software? Quality Assurance and Compliance Software Tools and Solutions 1
S DHF/DMR/MDF for a software-only, cloud-based, single-instance device Medical Information Technology, Medical Software and Health Informatics 2
H Software Validation for FFS Packaging Machine Qualification and Validation (including 21 CFR Part 11) 1
E Any sample of a full software life cycle IEC 62304 report ( any class )? IEC 62304 - Medical Device Software Life Cycle Processes 1
Q ISO 13485 7.5.6 Validation - Off the shelf Software ISO 13485:2016 - Medical Device Quality Management Systems 3
M ERP / QMS related software standards for Validation IEC 62304 - Medical Device Software Life Cycle Processes 6
J Do Software Subcontractors need to be ISO13485 compliant in the EU? EU Medical Device Regulations 3
D Safety data sheets software REACH and RoHS Conversations 2
N What are the software audit and control steps Reliability Analysis - Predictions, Testing and Standards 2
N Validating Software before getting approved as Class 2 device US Food and Drug Administration (FDA) 5
M Clinical Decision Support Software Question 21 CFR Part 820 - US FDA Quality System Regulations (QSR) 2
P Missing 1m visual alarm signal in case of software/display failure, mitigation? ISO 14971 - Medical Device Risk Management 3
B Software service provider as critical supplier ISO 13485:2016 - Medical Device Quality Management Systems 5
S Asterisk in DOE minitab software Using Minitab Software 23
M Surgical angle measurement guide device with an application software Medical Device and FDA Regulations and Standards News 1
M Advice needed for SEH Compliance Software and ISNETWord Compatabiliy Occupational Health & Safety Management Standards 2
bruceian Software Quality Metrics Software Quality Assurance 11
optomist1 How Secure Are Our Software Systems Software Quality Assurance 7
M 'Active' device? Software/laptop with attached camera 'looking' at passive metal probe EU Medical Device Regulations 3
D Software validation team Misc. Quality Assurance and Business Systems Related Topics 3
O Any info on release date of FDA “Computer Software Assurance for Manufacturing and Quality System Software” document? 21 CFR Part 820 - US FDA Quality System Regulations (QSR) 0
L Radiology software Class I exemption Medical Device and FDA Regulations and Standards News 3
O Software for comparing text of PDF files Contract Review Process 2
J Implementing an ISO 13485 QMS Software ISO 13485:2016 - Medical Device Quality Management Systems 6
K Software Updates in the Field and ISO scope ISO 13485:2016 - Medical Device Quality Management Systems 2
M Recurrent event analysis software (python) General Auditing Discussions 2
Y UL 1998 Standard: software classes Software Quality Assurance 0
P Need a programmer for QVI's VMS software for optical inspection machine Inspection, Prints (Drawings), Testing, Sampling and Related Topics 0

Similar threads

Top Bottom