How to handle Medical Device Emergency Software Releases

B

Bunny

Some background....
Medical Device Manufacturer of an electrical-mechanical Class 1, Exempt Medical Device.

Occasionally between scheduled software releases a customer will have an issue that a "hot fix" software will be created to address. For various reasons we can't hold the resolution until the next scheduled release. We are considering releasing these hot fixes to the Technical Service department to use as needed, but not releasing them to the Manufacturing department. Does anyone have experience where two versions of a software package are available? Does anyone have recommendations on how to handle this safely?
 

yodon

Leader
Super Moderator
Since you mention it's a class I device, I wouldn't expect a major concern for causing harm. So maybe an immediate field correction is not warranted. You would probably be well served to document a risk assessment and establish a roll-out plan. While it may not warrant a field correction, you probably want to issue a customer advisory notifying them of the issue and any remediation they need to take.

But to give a complete answer, more information is needed.

What's the impact of not releasing this to the field (updates to deployed devices)?

What does it mean to release to Tech Services "to use as needed"?

When you say "two versions of a software package" - can you distinguish between the 2? Without question, you need to be able to distinguish between the patched version and the baselined version (both in terms of 'source' and deployed; i.e., if you pick up a device, can you tell if it's running 1.0 or 1.1).

Depending on those answers, there may be more.

While exempt from design controls, at 'best' the software is a minor level of concern and so it would still be expected that the patched version is sufficiently verified (change tested and regression testing). Those activities need to be documented.

That's about all I can think of at the moment.
 
B

Bunny

This should help to answer your questions......

Our devices are used to connect third party medical devices into one system that the operator can control from one station. Think of it as a universal remote control for your extremely large and expensive home theater system. The hospital reporting the issue will have different medical imaging equipment than another hospital. So they may be the only hospital that sees the issue (a poor image on a SONY Camera for example). That is why Technical Support would "use as needed".

The software/firmware versions are identified with a control number, as you hinted to.

Once software/firmware files are released from Quality Control they are stored on a shared drive that Field and Manufacturing personnel can access. If we go this route and have intermediate sw/fw released to particular customers we do not want the wrong files inadvertently used. Our concern is with the in-house process, not so much with risk management and FDA reporting requirements.
 

yodon

Leader
Super Moderator
Sorry for the delay in replying, was on vacation.

I guess I'm still unclear as to how you identify the versions. Since you're not concerned about compliance, I'll stick with just following up on the release management aspect.

Let's say you formally release 1.0.0.0. I take it this is what you put on the shared drive? (NOTE: I intentionally used a 4 point system here thinking it might be something to the effect of "major release"."minor release"."bug fix"."site specific fix" - but you may well use something different).

Now, hospital A requires a hot fix, hospital B requires a different hot fix, and hospital C requires the fix for hospital A as well as a unique fix. Who makes those changes and how are they identified? Can the configuration for hospital A be distinguished from the baseline AND from the configuration for B and C?

After a while, you formally release 1.1.0.0. How do the hot fixes for A, B, and C get integrated into 1.1.0.0?

Unfortunately, patch (hot fix) management is a big challenge and can get complicated very quickly (consider the above just the tip of the iceberg). Having a good plan for managing is critical. The above questions are mainly rhetorical to stimulate thinking on the kinds of issues you're likely to encounter. To go further, I'd probably need to understand more about your specific process, version / revision numbering, and management practices.
 
Top Bottom