Software Device "Urgent" Releases? Software Change Control Process

[koes0030]

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?

 

[temujin]

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.

 

[koes0030]

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.

 

[mogluk]

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]

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).

 

[ddunn]

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.

 

[koes0030]

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.

 

[JaneB]

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]

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.

 

[Micked]

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

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"