Software updates considered servicing (7.5.4)

[yodon]

In a recent ISO 13485 audit of a company who is only marketing a stand-alone software application, the auditor said that software updates must be considered service activities per 7.5.4. I had never a) previously considered software updates as a service activity; or b) heard another auditor make such an assertion.

In several respects, software updates are not typical of a service activity in that instead of operating on an individual device, the entire application is re-built and re-distributed (even if only patching ... unless you have something like with antivirus software where you update definitions periodically without updating the entire application). Also, instead of being a specific service activity, in many cases, software updates may contain numerous changes, including new design. Finally, updates are done by the design and development team (and all the work effectively falls under design controls).

This was not written up as a finding, just a discussion. I'm curious what others' opinions / experiences are on this.

 

[Tidge]

This is a good topic for discussion. This feels like an area where some appeal to standards could be useful, but good luck finding appropriate ones. As far as my thoughts complying with 13485 clause 7.5.4, I will circle back, after a slight detour...

I believe (I have no sources immediately on had) that in the USA, for medical devices, there is a distinction made between:

• "Fast Patches"
• "Software Fixes"

My assessment is that a "Software Fix" would not be considered a Service Activity, per se... even if the "fix" is applied during some sort of service activity. Software fixes are supposed to have the full suite of supporting information based on the FDA's Level of Concern (similar to 62304's Software System Safety Classification, but not identical). This strikes me a a classic "development/design change" issue.

The "Fast Patches" are allowed (tolerated?) for cybersecurity reasons when the fast patch specifically (and only) targets identified defects and does not change any of the other functionality. I believe that in order to proceed with 'fast patches' it is necessary to belong to/participate in an "information sharing organization".

Now as far as clause 7.5.4 goes...

Applying "software fixes" ought to already be integrated within service activities. Presumably the fixes have been developed within a 62304-compliant process, and implemented through a deployment process compliant with other parts of 13485... so I doubt that this is where the auditor's interest was (assuming that good records of deploying software fixes are kept, analyzed, etc.)

The "Fast Patches" for cybersecurity are a little trickier... as near as I can tell, the FDA has a compromise/balance that hinges on (a) specifically identifying the vulnerability being fixed and (b) not touching other elements of the software system... so the "verifying that (product requirements are met" after a fast patch is not supposed to be burdensome. Another dimension of the need for a "fast patch" is almost certainly NOT coming from a customer (remember: your company was supposed to be participating in an "information sharing org") so ties to the 'complaint process' can be... different than the a more classic complaint generated from a service activity.

If there is any good (where in this instance good = 'less burdensome") news: The servicing clause presumably only applies to the activities that the organization actually undertakes. I don't mean to write that risks of un-patched software could be unacceptable, just that such an assessment is presumably in a different part of 13485.

I am also curious to read others thoughts.

 

[shimonv]

servicing is a pre-planned routine maintenance activity and in the case of stand-alone software it's rare.
I guess you could include under 'servicing activity' checking/ cleaning up of log files, verifying that the software files have not been deleted or modified etc. Note: the software can do all that automatically during start-up.
Nearly all software relating activities are development activities - enhancements, responses to complaints and new features.

Shimon

 

[somashekar]

This activity is to be supported with how the controls are in place for post-delivery activities as in clause 7.5.1 f) of the ISO 13485:2016.
This activity does not fall into the servicing activities. The intent in 7.5.4 is about on site / service centre activity of servicing a medical device depending upon the type of medical device. Very typically, if 7.5.3. is applicable, then 7.5.4 is applicable, but some medical devices having no installation activities can also be covered by the company under its warranty and post warranty servicing.

 

[yodon]

Follow-up... I had an email chat with the auditor to see if he would provide more insight. He agreed that not all software updates would / should be considered a service activity. He suggested there are cases for service, like I mentioned above (definition updates, etc. that don't change the build). At least he and I are, I think, on the same page now. We'll see.