Software Device "Urgent" Releases? Software Change Control Process

K

koes0030

#1
Hi all,

I am working on helping my company better define their software change control process. Currently, we have a standard process that is used for planned releases, and a "hot fix" that is used for more urgent releases... currently, the only difference between the two processes is the ability to use an abridged testing plan for the hot fixes... a review board meets to determine and document which tests must be done, which ones don't, etc... for some simple fixes, not much testing is needed. Today we were discussing the potential need for an immediate/critical fix... in the event that the service goes down, or a really nasty bug(maybe potential for risk to patient safety) is found, our engineers would like the ability to deploy a fix ASAP, prior to getting all of the documentation in place, performing all the validation/verification testing, etc.

In our regulated world, I'm not seeing how we can make this work... how could it ever be OK to push software to production (release a device) prior to testing it to make sure it is safe and works properly? Then again, I'm new to the software device realm, so I'm wondering if anybody has any insight on this matter. Is this totally impossible?
 
Elsmar Forum Sponsor
T

temujin

#2
Hi,

Do you keep track of where your SW is installed and which customer has which version?

I believe a bug that could compromise the safety of the patient should be detected prior to release. Anyway, in case it does not, do you have mechanisms in place for a recall?

regards
t.
 
K

koes0030

#3
Yes we do. Our software is installed in-house and accessed remotely... no installation at any other site... so there is only one version in production at any given time. We also have a process for documenting who is utilizing our software, so in the event of a problem or recall we can notify all the affected users.
 
M

mogluk

#4
unfortunately I don't think taht you can get away from any verification, thats a requirement (I am US so following FDA and ISO). But depending on your time frame, you should be able to perform emergencey fix (design SRS, hazard/risk, and verification within one business day) and get taht out the door. but Ultimately you have to have verification prior to it leavingyour hands at teh very least.... you might be able to squeeze out Validation with a justification...that its a bug fix and no any additional new feature.
 

yodon

Staff member
Super Moderator
#5
So I presume the software itself is not a medical device. I suppose if the software can't harm anyone or cannot contribute to a quality (system) malfunction then you might be justified in rolling it out without validation.

I think mogluk gave good advice but I would recommend that you supplement your justifcation with a risk assessment. That would at least show you thought things out and made a rational decision on what to do.

I, personally, would find it very difficult to release modified software without some testing. Too many ways software can break unexpectedly. In fact ,we test not only the fix but do an assessment of what's 'around' the fix and test that as well (regression testing).
 
D

ddunn

#6
I usually found that when verification is bypassed and software is delivered without testing or documentation, no matter how urgent the need is the "fixed" software will make the original problem worse, it will take 10 times longer to fix and test it and your customer will be very angry.

Murphy's Law and all that stuff.
 
K

koes0030

#7
So I presume the software itself is not a medical device. I suppose if the software can't harm anyone or cannot contribute to a quality (system) malfunction then you might be justified in rolling it out without validation.

I think mogluk gave good advice but I would recommend that you supplement your justifcation with a risk assessment. That would at least show you thought things out and made a rational decision on what to do.

I, personally, would find it very difficult to release modified software without some testing. Too many ways software can break unexpectedly. In fact ,we test not only the fix but do an assessment of what's 'around' the fix and test that as well (regression testing).
Nope... in this case, the software IS the medical device, and could concievably harm somebody. Which makes it all the more difficult to release without some testing! We are going to proceed with the requirement that some level of testing must be completed, though it can be abridged to specific tests if appropriately justified. I'm sure the engineers will be sad not to have that additional flexibility, but oh well... it's part of the fun of living in this regulated environment.
 
J

JaneB

#8
in this case, the software IS the medical device, and could concievably harm somebody. Which makes it all the more difficult to release without some testing! We are going to proceed with the requirement that some level of testing must be completed, though it can be abridged to specific tests if appropriately justified. I'm sure the engineers will be sad not to have that additional flexibility, but oh well... it's part of the fun of living in this regulated environment.
I think you're absolutely right to be concerned, and like you, I do NOT see how one could argue that a 'quick fix' without testing is OK. It isn't.

Engineers often/usually wanna push it through quickly, and software people are, I'm afraid to say, often the worst at it because they are sure they 'know' that it'll be OK.

Look - this kind of thing happens in just about every field - 'quality' is fine until it's an urgent/rush/immediate job, in which case short-sighted people want to drop the requirements and just push it on out there. Which is almost invariably when it goes wrong.

The trick, no doubt, is going to be to balance the need for an urgent release (interesting - why is it so urgent by the way?? how many 'urgents' are there? and are they a symptom that the initial pre-release testing wasn't robust enough?) vs the need to maintain QA, and find hopefully something that effectively responds to both.
 

Marcelo

Inactive Registered Visitor
#9
IEC 62304:2006 - Medical device software - Software life cycle processes haqs requirements for different processes related to medical device software, including software maintenance process, software configuration management process, software risk management process and software problem resolution process.

Might help.
 
M

Micked

#10
Marcelo is right, this is a no-brainer at least to me.
IEC 62304 states:
"Has the change been verified, including repeating any verification that has been invalidated by the change and taking into account 5.7.3 (regression testing) and 9.7?"

This doesn't mean you have to produce a ton of paper for every tiny bug:bonk:

I am designing a process like this for my client right now. My plan is to write a very short mini-project plan in the change request itself. That should state the necessary verification needed and possibly some reasonable regression testing.
If you have a sound process for approving change requests then you should be on the safe side.

"Make it simple to make them make it"
 
Thread starter Similar threads Forum Replies Date
R Shall a new UDI-DI be required when stand-alone software device's version is updated? EU Medical Device Regulations 1
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
A Software as Medical Device (SaMD) definition and its applicability Other Medical Device and Orthopedic Related Topics 4
T First 510(k) submission - Class II software as medical device US Food and Drug Administration (FDA) 1
Z Software Library - could it be a medical device? ISO 13485:2016 - Medical Device Quality Management Systems 5
M Informational TGA – Submissions received: Regulation of software, including Software as a Medical Device (SaMD) Medical Device and FDA Regulations and Standards News 1
D Requirements for the dimensions / color of medical device labels - Software as a Medical Device IEC 62304 - Medical Device Software Life Cycle Processes 2
D Software as an accessory to a Class I medical device EU Medical Device Regulations 4
R Medical device software without user interface Other Medical Device and Orthopedic Related Topics 3
R Validation of Medical Device Hardware containing Software - How many to Validate ISO 13485:2016 - Medical Device Quality Management Systems 1
Ed Panek Rule 11 Question - CE approvals for software as well as the medical device EU Medical Device Regulations 6
D IEC 60601 for a Software only Medical Device? IEC 60601 - Medical Electrical Equipment Safety Standards Series 5
S Software Release Note - Class A stand alone software medical device IEC 62304 - Medical Device Software Life Cycle Processes 2
K Unique Device Identifier for updates to legacy standalone software Other US Medical Device Regulations 1
M Professional Use Medical Software French Labeling for Canada -- Not Considered Medical Device Canada Medical Device Regulations 2
S Medical Device Software Distribution for a CE-marked medical device via a USB memory stick EU Medical Device Regulations 8
M Informational TGA – Webinar: An update on the consultation for the Regulation of Software, including Software as a Medical Device (SaMD) Medical Device and FDA Regulations and Standards News 0
B Class IIB Device - IEC 62304 Software Classification IEC 62304 - Medical Device Software Life Cycle Processes 13
J Qualification of a Software as a Medical Device (SaMD) guidance under MDR EU Medical Device Regulations 9
P Software requirement and design specifications - Medical device contains both hardware and software IEC 62304 - Medical Device Software Life Cycle Processes 2
M Informational TGA Consultation: Regulation of software, including Software as a Medical Device (SaMD) Medical Device and FDA Regulations and Standards News 0
N Medical Device Accessory Classification - Software as a Medical Device Other Medical Device Regulations World-Wide 5
R SaMD - Software as a Medical Device - Software change control form ISO 13485:2016 - Medical Device Quality Management Systems 3
G EU MDR 2017/745 Rule 11 interpretation - Re-classification of a Software as Medical Device Other Medical Device Related Standards 0
M FDA News Digital Health Update: USFDA Report on Non-Device Software Functions Now Available Medical Device and FDA Regulations and Standards News 0
M Medical Device News TGA – Regulation of Software as a Medical Device Medical Device and FDA Regulations and Standards News 0
S Two Questions about Medical Device Software 21 CFR Part 820 - US FDA Quality System Regulations (QSR) 3
K Medical Device Software Update in Field of AIMD IEC 62304 - Medical Device Software Life Cycle Processes 1
M Medical Device News Health Canada - Scientific Advisory Panel on Software as a Medical Device (SAP-SaMD) - Record of Proceedings – January 26, 2018 Canada Medical Device Regulations 0
R Online / Cloud Based Software as Medical Device EU Medical Device Regulations 8
S DMR (Device Master Record) for Medical Device Software IEC 62304 - Medical Device Software Life Cycle Processes 3
S Labelling in Medical Device Software IEC 62304 - Medical Device Software Life Cycle Processes 8
S What is considered the complete software medical device? Medical Information Technology, Medical Software and Health Informatics 6
JoCam Medical Device Software - Apps which can control medical devices EU Medical Device Regulations 13
L Software Medical Device - 7.3.8 - Design and Development Transfer ISO 13485:2016 - Medical Device Quality Management Systems 4
A SOP for software validation of software in medical device IEC 62304 IEC 62304 - Medical Device Software Life Cycle Processes 5
K Registering a Software medical device (SaMD) in China China Medical Device Regulations 5
N Medical Device Software - Switch from Waterfall to Agile methodology Medical Information Technology, Medical Software and Health Informatics 4
V Software medical device labelling EU Medical Device Regulations 5
I Medical Device Software Risk Analysis ISO 14971 - Medical Device Risk Management 4
S If a piece of software receives approval as part of a medical device system Canada Medical Device Regulations 5
C Controlling Software Versions that are part of a medical device IEC 62304 - Medical Device Software Life Cycle Processes 2
S Cloud-Based Stand Alone Software - Software Medical Device (Class II) US Food and Drug Administration (FDA) 2
J PMA Device - Lot # change in New ERP Software - What are the FDA Requirements 21 CFR Part 820 - US FDA Quality System Regulations (QSR) 0
Q QMS Software for Startup Medical Device Company Other Medical Device and Orthopedic Related Topics 7
B CQC oversight of Medical device software? EU Medical Device Regulations 3
H Identifying Guidance on Medical Device Software Level of Concern for the EU EU Medical Device Regulations 2
B Is IEC TR 80002-1:2009 applicable to stand-alone medical device software? ISO 14971 - Medical Device Risk Management 1
H ISO 14971 vs. IEC 62304 vs. 98/79/EC vs. ISO 13485 (Software Medical Device) ISO 14971 - Medical Device Risk Management 1
Similar threads


















































Top Bottom