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

Leader
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

Leader
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
I SaMD Software bug and issue tracking. Manufacturing and Related Processes 1
MaHoDie Where to show the Software version IEC 62304 - Medical Device Software Life Cycle Processes 2
W Looking for IATF 16949 (and ISO 17025) QMS software Suggestions Quality Tools, Improvement and Analysis 8
9 ECi M1 Software Consultants in Ohio Manufacturing and Related Processes 0
T SaMD or Software system? EU Medical Device Regulations 2
I Registration of MD software IEC 62304 - Medical Device Software Life Cycle Processes 0
Q Quality Plan for eQMS software ISO 13485:2016 - Medical Device Quality Management Systems 2
Ed Panek Validation of Signature Software (Off the shelf) US Medical Device Regulations 3
C FMEA Software Report View FMEA and Control Plans 1
jeancloude17 Advice for ISO 9001 for software Design and Development of Products and Processes 2
T Determination of Software/system end-of-life IEC 62304 - Medical Device Software Life Cycle Processes 5
D Software Bill of Materials (SBOM) preparation Other Medical Device Related Standards 6
D Software Registration GUDID 21 CFR Part 820 - US FDA Quality System Regulations (QSR) 0
Sam.F Quotation software or spreadsheet Contract Review Process 2
T IVD Device Software - Risk Classification IEC 62304 - Medical Device Software Life Cycle Processes 16
T Wanted: Software for Developing Front-end Interfaces to (SQL) Databases Quality Tools, Improvement and Analysis 1
M Software "Nonconformances" ISO 13485:2016 - Medical Device Quality Management Systems 21
M Software as Medical Device import activities for Chile and Mexico Other Medical Device Regulations World-Wide 0
J Document Control of Online Management Software ISO 9000, ISO 9001, and ISO 9004 Quality Management Systems Standards 10
S Functionality of software in countries with different legal requirements IEC 62304 - Medical Device Software Life Cycle Processes 2
J Using an online software to maintain your QMS Quality Assurance and Compliance Software Tools and Solutions 7
R Quality System Software AS9100, IAQG, NADCAP and Aerospace related Standards and Requirements 8
V Software license key regulatory requirements Medical Information Technology, Medical Software and Health Informatics 2
I Request for information regarding remote medical monitoring software (its technical documentation and the IUD system) IEC 62304 - Medical Device Software Life Cycle Processes 2
M Software Validation SAP B1 for ERP ISO 13485:2016 - Medical Device Quality Management Systems 2
P Computer Software Assurance Software Quality Assurance 2
P Software validation for FPGA Software Quality Assurance 1
R IVD Software FDA/CLIA doubts Medical Device and FDA Regulations and Standards News 1
R IVD software FDA and CLIA US Food and Drug Administration (FDA) 2
G Software verification vs. system verification IEC 62304 - Medical Device Software Life Cycle Processes 3
S Process Monitoring using SPC software Quality Assurance and Compliance Software Tools and Solutions 6
J Megger MIT520/2 adjustment software? Calibration and Metrology Software and Hardware 0
M Product Acceptance Software (PAS) PROCEDURE (BOEING D6-51991) AS9100, IAQG, NADCAP and Aerospace related Standards and Requirements 3
M 3D Scanner Software validation ISO 13485:2016 - Medical Device Quality Management Systems 7
Y Software to Manage IEC 62304 Traceability Requirement IEC 62304 - Medical Device Software Life Cycle Processes 3
T Software item classification and Detailed Design IEC 62304 - Medical Device Software Life Cycle Processes 4
T Software Unit definition - IEC 62304 - Medical Device Software Life Cycle Processes 3
T Software user interface - definition of hazards ISO 14971 - Medical Device Risk Management 15
T Classification Accessory Software medical device EU Medical Device Regulations 4
G Software Medical Device Classification EU Medical Device Regulations 7
D Software Validation Question ISO 13485:2016 - Medical Device Quality Management Systems 10
C. Tejeda Computer system validation approach for Minitab Statistical software Software Quality Assurance 11
B Can a software that receive data from a MD be classified as Class I?or is not a MD? EU Medical Device Regulations 5
A What JIRA Software workflows you use for your software lifecycle? IEC 62304 - Medical Device Software Life Cycle Processes 4
G Software change management Design and Development of Products and Processes 3
G IATF 7.1.5.2.1 Calibration/verification records :Program/software verification IATF 16949 - Automotive Quality Systems Standard 7
John C. Abnet ...validation of computer software ISO 13485:2016 - Medical Device Quality Management Systems 17
N Free statistical software Reliability Analysis - Predictions, Testing and Standards 7

Similar threads

Top Bottom