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
E 13485:2016, Sections 4.1.6, 7.5.6 and 7.6 - Validation of Software - Need some Advice please ISO 13485:2016 - Medical Device Quality Management Systems 2
R Medical Device Software Certification IEC 62304 - Medical Device Software Life Cycle Processes 1
S HIPAA-compliant monitoring software (advice needed) Hospitals, Clinics & other Health Care Providers 0
A Software bug fixes after shipping a product EU Medical Device Regulations 3
J Medical software Patient outcome Medical Information Technology, Medical Software and Health Informatics 2
Y We are Looking for EASA LOA TYPE 1 experienced software developer Job Openings, Consulting and Employment Opportunities 0
F Grand Avenue Software, Q-Pulse or Qualio - which for a full eQMS? Medical Information Technology, Medical Software and Health Informatics 1
K SOUP (Software of Unknown Provenance) Anomaly Documentation IEC 62304 - Medical Device Software Life Cycle Processes 2
Q Storing and developing SAMD (Software as a Medical Device) in the Cloud IEC 62304 - Medical Device Software Life Cycle Processes 2
I Old Time Scatter diagrams for defect type and location- software Quality Tools, Improvement and Analysis 3
SocalSurfer AS9100 new certificate, but need QMS software, help Quality Assurance and Compliance Software Tools and Solutions 2
C Is my software an accessory? Telecommunication between HCP and patients EU Medical Device Regulations 10
K Verify Software Architecture - supporting interfaces between items IEC 62304 - Medical Device Software Life Cycle Processes 1
A What are the pros and cons of using an audit software for internal auditing? General Auditing Discussions 4
A Risk Number for each software requirement IEC 62304 - Medical Device Software Life Cycle Processes 7
R Shall a new UDI-DI be required when stand-alone software device's version is updated? EU Medical Device Regulations 1
R MSA for ATE (Automatic Test Equipment Embedded Software) Gage R&R (GR&R) and MSA (Measurement Systems Analysis) 9
S MDR GSPR Clause 17 - Software Requirements EU Medical Device Regulations 2
L Turkish Requirements - Does the Software need to be translated? CE Marking (Conformité Européene) / CB Scheme 2
MDD_QNA Medical Device Software - Is a Help Button required? IEC 62304 - Medical Device Software Life Cycle Processes 1
F Software as a Medical Device (SaMD) Technical File Requirements Manufacturing and Related Processes 1
D Software User Interface Languages for LVD and IVD CE Marking (Conformité Européene) / CB Scheme 2
A Software as Medical Device (SaMD) definition and its applicability Other Medical Device and Orthopedic Related Topics 4
K Software Validation for Measurement Tools used in Process Validation ISO 13485:2016 - Medical Device Quality Management Systems 2
B ISO 14971 Applied to Software ISO 14971 - Medical Device Risk Management 2
N ERP Software Implementation Manufacturing and Related Processes 3
C NCR (Nonconformance System) Software Nonconformance and Corrective Action 7
U Document Approval - Software company ISO 9000, ISO 9001, and ISO 9004 Quality Management Systems Standards 3
B Risk Assessment Checklist for Non product Software IEC 62304 - Medical Device Software Life Cycle Processes 1
MrTetris Should potential bugs be considered in software risk analysis? ISO 14971 - Medical Device Risk Management 5
S SOP for ISO 13485:2016 Quality related Software validation ISO 13485:2016 - Medical Device Quality Management Systems 9
J Designing new gauge tracking software IATF 16949 - Automotive Quality Systems Standard 4
T First 510(k) submission - Class II software as medical device US Food and Drug Administration (FDA) 1
B Notified Bodies for Software (MDR) EU Medical Device Regulations 1
C MDR - Question around software accesories EU Medical Device Regulations 2
S Software for Supplier Charge back and internal PPM General Information Resources 2
G Assignable cause/corrective action list for SPC Software Statistical Analysis Tools, Techniques and SPC 3
K ERP System Software Validation - ISO13485 2016 4.1.6 Design and Development of Products and Processes 8
S Recommendation for user friendly Gaga R&R and Cpk software Gage R&R (GR&R) and MSA (Measurement Systems Analysis) 10
M HR (Human Resources) based software recommendations Human Factors and Ergonomics in Engineering 2
V Gage Management and Gage R&R Software General Measurement Device and Calibration Topics 1
F Medical Devices-South Africa _Post approval changes and Software Other Medical Device Regulations World-Wide 0
Marc Security in Health Industry Software - February 2020 IEC 27001 - Information Security Management Systems (ISMS) 0
D Software validation in Medical Equipment Other Medical Device and Orthopedic Related Topics 20
C Experience with Agile PLM (Product Lifecycle Management Software) software from Oracle? Document Control Systems, Procedures, Forms and Templates 3
JoCam Software Translation under MDR requirements EU Medical Device Regulations 5
W Air Quality Measurement Hardware and Software General Measurement Device and Calibration Topics 11
Q Is that any difficulty to do software DFMEA and PFMEA in ISO 13485? ISO 13485:2016 - Medical Device Quality Management Systems 5

Similar threads

Top Bottom