Do Software Upgrades Fall Under the Definition of Recall per SOR/98-202?

blah01

Involved In Discussions
#1
We produce a standalone software considered as a Class I medical device under this MDR. During our last HC inspection, the inspector told us that all field software upgrades should be considered a ‘recall’ based on point ‘b’ of the definition which reads as follows:
(b) may fail to conform to any claim made by the manufacturer or importer relating to its effectiveness, benefits, performance characteristics or safety;

Like any software product, we occasionally have field upgrades to improve functionality or slight anomalies detected over time. However, being a Class I device, these do not pose any risks to users. We therefore find it to be an extreme interpretation that any field upgrades have to be reported per the Recall requirements (sections 63-65).

I’m hoping to get feedback regarding interpretation of the Recall definition and requirements in the context of software upgrades.

Note that I browsed through several threads in the ‘Canada Medical Device Regulations’ forum already and couldn’t find anything about Recall. If there is such a thread I’d appreciate a link to it.

Thanks in advance.
 
Elsmar Forum Sponsor

shimonv

Trusted Information Resource
#2
Hi blah01,
Let's zoom out for a second. This is what the HC guidance says:

================\\
"Recall" is defined in the MDR as follows:

A "recall" in respect of a medical device that has been sold, means any action taken by the manufacturer, importer or distributor of the device to recall or correct the device, or to notify its owners and users of its defectiveness or potential defectiveness, after becoming aware that the device:

(a) may be hazardous to health
(b) may fail to conform to any claim made by the manufacturer or importer relating to its effectiveness, benefits, performance characteristics or safety
(c) may not meet the requirements of the Food and Drugs Act or these regulations

A recall may include:

- removing a medical device from the market
- instructing customers to stop using a medical device and destroying remaining units in stock
- doing an on-site correction of a medical device
- advising users of a device about a problem or potential problem
- supplying different labelling (which may include updates to instructions or manuals)"
=================\\.

The regulator doesn't want to be bothered by every little change that you do. If this was the case then they wouldn't be able to cope with the amount of recall notifications.

The examples in the guidance document shows that that recall is about changes with significant impact on safety or effectiveness.

The inspector was latching onto point "b". Please not that the word "claim". It's about the major features of the device that fulfill its intended use. It's not about small enhancements or minor fixes.
Of course, there is some grey area between enhancement, a fix with no impact on safety and effectiveness and a fix which comes in response to safety or effectiveness issue.
The way you justify your decision is through your documentation and risk analysis.

-Shimon
 
Last edited:

mihzago

Trusted Information Resource
#3
I concur with Shimonv's suggestion.
Maybe what the inspector was saying is that you should consider recall requirements whenever you make software changes.
What I do to address this, when I document the change, I include a brief paragraph with an assessment explaining why this change is not considered recall.
 
A

Access2hc

#4
I concur with shimonv's opinions. just to focus a bit more on the justification of each bug fix or enhancement.

in the unlikely event that the software fails to meet (any part of) its intended use, and has an impact on safety/performance, perhaps a consultation with the regulator is required.

most events are due to nuisance software events, or errors/inefficiencies of the workflow that does not impact the intended function of the software, or that the user wants to give feedback about the usability of the software which again does not impact on the intended purpose or the safety/performance of the software. these are not reportable

hope it helps

Cheers,
Ee Bin
@Access2HC
 

blah01

Involved In Discussions
#5
Thanks everyone for the useful feedback. This really helped clarify things.

All I've decided to do is make an amendment to our change review record, which already has a section to identify if a Recall is applicable or not, to now also capture the rationale why a Recall is not applicable. I am thinking of using the following as standard text going forward:
"Fixes in this release have no correlation to product claims, intended use or safety."

I'd appreciate feedback if you think I should tweak this statement, otherwise thanks again for the help.
 
Thread starter Similar threads Forum Replies Date
M Initial Importer/Distributor and Software Validation IEC 62304 - Medical Device Software Life Cycle Processes 0
F Configurator for a power unit - Software or other solution? Manufacturing and Related Processes 0
D Test Management Software Software Quality Assurance 1
E ISO 13485 software validation ISO 13485:2016 - Medical Device Quality Management Systems 7
D Tracking software versions used with instruments ISO 13485:2016 - Medical Device Quality Management Systems 0
dgrainger Informational MHRA's Software and AI as a Medical Device Change Programme UK Medical Device Regulations 0
S Do you follow your QMS for non-device software features? Medical Information Technology, Medical Software and Health Informatics 4
J Can we register non-device clinical decision support software under draft guidance? Other US Medical Device Regulations 5
I Software (SaMD) mobile application verification testing: objective evidence Medical Information Technology, Medical Software and Health Informatics 2
J EU equivalent to Clinical Decision Support Software EU Medical Device Regulations 3
Y ISO 13485:2015 Software Validation IQ/OQ/PQ ISO 13485:2016 - Medical Device Quality Management Systems 13
S Recommended software to send Quality scorecards to suppliers (external providers) Supplier Quality Assurance and other Supplier Issues 3
J Software as a Medical Device - SaMD IEC 62304 - Medical Device Software Life Cycle Processes 3
BeaBea QMS/ Training Management Software Service Industry Specific Topics 4
shimonv Working with a software developer who is not setup for IEC 62304 IEC 62304 - Medical Device Software Life Cycle Processes 9
R Debug mode in software/device validation IEC 62304 - Medical Device Software Life Cycle Processes 2
Q Gage calibration / tracking software General Measurement Device and Calibration Topics 5
M Software verification and validation AS9100 AS9100, IAQG, NADCAP and Aerospace related Standards and Requirements 4
Y RT-qPCR Software result EU Medical Device Regulations 0
B A.I diagnostic software is considered as medical device in FDA? US Food and Drug Administration (FDA) 5
F WANTED Senior Software engineer Career and Occupation Discussions 2
P Blood establishment computer software EU classification EU Medical Device Regulations 0
S Examples of FDA acceptable Software Design Specification (SDS) Medical Device and FDA Regulations and Standards News 6
D Integrated Management System Software Quality Manager and Management Related Issues 2
B Sampling strategies/techniques for software QA Software Quality Assurance 3
K MDCG-2020-3 (about the software of UI) EU Medical Device Regulations 3
D PFMEA Software search IATF 16949 - Automotive Quality Systems Standard 7
C MDR software classification EU Medical Device Regulations 12
H Class II a vs "software safety class A" IEC 62304 - Medical Device Software Life Cycle Processes 4
Z Software for design control ISO 13485:2016 - Medical Device Quality Management Systems 5
V Medical Device Literature Translation Software ISO 13485:2016 - Medical Device Quality Management Systems 1
D FDA Guidance on Computer Software Assurance versus 21 CFR Part 11 21 CFR Part 820 - US FDA Quality System Regulations (QSR) 2
P Software verification and validation procedure IEC 62304 - Medical Device Software Life Cycle Processes 6
Aymaneh UDI-PI Software CE Marking (Conformité Européene) / CB Scheme 0
Q Software as a medical device vs software not sold as medical device: local regulations for sale? EU Medical Device Regulations 4
Y Software updates considered servicing (7.5.4) ISO 13485:2016 - Medical Device Quality Management Systems 4
S How to perform verification of the Statistical Analysis Software? Qualification and Validation (including 21 CFR Part 11) 7
I Document Control Software Document Control Systems, Procedures, Forms and Templates 2
E Software maintenance Process Software maintenance Process to IEC 6204? IEC 62304 - Medical Device Software Life Cycle Processes 3
L Micro-Vu InSpec Software Program Qualification and Validation (including 21 CFR Part 11) 6
A For software change - New Channel of interoperability CE Marking (Conformité Européene) / CB Scheme 5
T IVDR Medical device software CE Marking (Conformité Européene) / CB Scheme 8
N ISO 13485 7.3.9 Change control in medical device software ISO 13485:2016 - Medical Device Quality Management Systems 6
C SharePoint Contract Management Software General Information Resources 0
gramps What do you think about automated QA testing For software app industry? Misc. Quality Assurance and Business Systems Related Topics 5
V Software as medical device (SaMD) replicated for multiple clients through APIs IEC 62304 - Medical Device Software Life Cycle Processes 5
U API Spec Q1 - 5.6.1.2 C (3) - Design software Oil and Gas Industry Standards and Regulations 3
B Complaint Records - Accessing records on Easy Track Software Records and Data - Quality, Legal and Other Evidence 3
GreatNate Master Control QMS software Quality Tools, Improvement and Analysis 1
GreatNate Anyone using the Intellect QMS software? Quality Assurance and Compliance Software Tools and Solutions 1

Similar threads

Top Bottom