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.
 

Access2hc

Involved In Discussions
#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 Recurrent event analysis software (python) General Auditing Discussions 2
Y UL 1998 Standard: software classes Software Quality Assurance 0
P Need a programmer for QVI's VMS software for optical inspection machine Inspection, Prints (Drawings), Testing, Sampling and Related Topics 0
S IEC 62304 software costs and time Medical Device and FDA Regulations and Standards News 2
S IEC 62304 - Software verification cost IEC 62304 - Medical Device Software Life Cycle Processes 3
Sravan Manchikanti Software Risk Management & probability of occurrence as per IEC 62304 IEC 62304 - Medical Device Software Life Cycle Processes 8
I Form templates for software (iso9001) Document Control Systems, Procedures, Forms and Templates 0
H Software Interface Translation IVD Regulation EU Medical Device Regulations 0
C 8.5.1.1 Control of Equipment, Tools, and Software Programs - Questions about the extent of control of NC programs AS9100, IAQG, NADCAP and Aerospace related Standards and Requirements 5
M IEC 62304 Software changes - Minor labeling changes on the GUI IEC 62304 - Medical Device Software Life Cycle Processes 3
silentmonkey Rationalising the level of effort and depth of software validation based on risk ISO 13485:2016 - Medical Device Quality Management Systems 10
T Do I need a qualified compiler for class B software? IEC 62304 - Medical Device Software Life Cycle Processes 3
S Manufacturing Execution Systems Software Costs Manufacturing and Related Processes 0
E 13485:2016, Sections 4.1.6, 7.5.6 and 7.6 - Validation of Software - Need some Advice please ISO 13485:2016 - Medical Device Quality Management Systems 2
R Medical Device Software Certification IEC 62304 - Medical Device Software Life Cycle Processes 1
S HIPAA-compliant monitoring software (advice needed) Hospitals, Clinics & other Health Care Providers 0
A Software bug fixes after shipping a product EU Medical Device Regulations 3
J Medical software Patient outcome Medical Information Technology, Medical Software and Health Informatics 2
Y We are Looking for EASA LOA TYPE 1 experienced software developer Job Openings, Consulting and Employment Opportunities 0
F Grand Avenue Software, Q-Pulse or Qualio - which for a full eQMS? Medical Information Technology, Medical Software and Health Informatics 1
K SOUP (Software of Unknown Provenance) Anomaly Documentation IEC 62304 - Medical Device Software Life Cycle Processes 2
Q Storing and developing SAMD (Software as a Medical Device) in the Cloud IEC 62304 - Medical Device Software Life Cycle Processes 2
I Old Time Scatter diagrams for defect type and location- software Quality Tools, Improvement and Analysis 3
SocalSurfer AS9100 new certificate, but need QMS software, help Quality Assurance and Compliance Software Tools and Solutions 2
C Is my software an accessory? Telecommunication between HCP and patients EU Medical Device Regulations 10
K Verify Software Architecture - supporting interfaces between items IEC 62304 - Medical Device Software Life Cycle Processes 1
A What are the pros and cons of using an audit software for internal auditing? General Auditing Discussions 4
A Risk Number for each software requirement IEC 62304 - Medical Device Software Life Cycle Processes 7
R Shall a new UDI-DI be required when stand-alone software device's version is updated? EU Medical Device Regulations 1
R MSA for ATE (Automatic Test Equipment Embedded Software) Gage R&R (GR&R) and MSA (Measurement Systems Analysis) 9
S MDR GSPR Clause 17 - Software Requirements EU Medical Device Regulations 2
L Turkish Requirements - Does the Software need to be translated? CE Marking (Conformité Européene) / CB Scheme 2
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
D Software User Interface Languages for LVD and IVD CE Marking (Conformité Européene) / CB Scheme 2
A Software as Medical Device (SaMD) definition and its applicability Other Medical Device and Orthopedic Related Topics 4
K Software Validation for Measurement Tools used in Process Validation ISO 13485:2016 - Medical Device Quality Management Systems 2
B ISO 14971 Applied to Software ISO 14971 - Medical Device Risk Management 2
N ERP Software Implementation Manufacturing and Related Processes 3
C NCR (Nonconformance System) Software Nonconformance and Corrective Action 7
U Document Approval - Software company ISO 9000, ISO 9001, and ISO 9004 Quality Management Systems Standards 3
B Risk Assessment Checklist for Non product Software IEC 62304 - Medical Device Software Life Cycle Processes 1
MrTetris Should potential bugs be considered in software risk analysis? ISO 14971 - Medical Device Risk Management 5
S SOP for ISO 13485:2016 Quality related Software validation ISO 13485:2016 - Medical Device Quality Management Systems 9
J Designing new gauge tracking software IATF 16949 - Automotive Quality Systems Standard 4
T First 510(k) submission - Class II software as medical device US Food and Drug Administration (FDA) 4
B Notified Bodies for Software (MDR) EU Medical Device Regulations 1
C MDR - Question around software accesories EU Medical Device Regulations 2
S Software for Supplier Charge back and internal PPM General Information Resources 2
G Assignable cause/corrective action list for SPC Software Statistical Analysis Tools, Techniques and SPC 3

Similar threads

Top Bottom