Software for a Class II Medical Device - Required Advice for 510(k)

M

manju.ado

#1
Hi,

We are developing software for a class II Medical Device. We are adding a small new functionality to software and this change to software is very minimal. The new functionality is independent of other functionalities software. Addition of this functionality will not affect the existing software in any manner. The old software is being approved by FDA and in the market quite some time.

I have following queries:

1. In this scenario, do we need to go for traditional 510(k) or Special 510(k)?
2. What would DHF contain? Only design history of new functionality and impact analysis document to claim that new functionality will not be affecting old functionalities? Or do we need create all the design history documents for all old functionalities also.

Please advice.

Thank you in advance.

Regards,

Manju
+91-9011081376
 
Elsmar Forum Sponsor

sagai

Quite Involved in Discussions
#2
Hi,
I am only wondering in case the new functionality is absolutely independent from the old one, than there is a potential, that your original intended use has changed, due to you can not relate the new function to any earlier one.
And if it is the case, you have to have a traditional one.
Special 510k looks tempting, but you shall declare conformance with a couple of standards in that case.
br
Sz.
 
M

manju.ado

#3
Hi Sagai,

Thank you for your reply. It’s indeed useful.

Actually indented usage won’t change but there could be minor change in indication for use, however it is very negligible.

When I follow the flow-chart B of document “Deciding When to Submit a 510(k) for a Change to an Existing Device” (attached document) through changes to software or firmware (B8 - section), I’ll be reaching to “Documentation”, with certain level of presumptions at this point of time.

1. What exactly documentation meant here? And what all it contains?
2. As 510(k) no ware appearing (new or traditional / abbreviated or special), in this case actually 510(k) itself is required.

Please advice.

Appreciate your help.

Regards,

Manju

 

Attachments

sagai

Quite Involved in Discussions
#4
Hi,
I'm not sure the change of sw functionality can be categorized among:
"labeling changes, technology or performance specifications changes, and materials changes"
and as such I am not sure this guidance is applicable to your situation.
I feel the traditional 510k is the one required, I would drop special/abbreviated because why would you create more specific requirements to your QMS than already there. The timing of the 510k can be a question.
br
Sz.
 
M

manju.ado

#5
Thank you Sagai.

Then what should we do if this document as such is not applicable to us, should we contact FDA for more clarification or are there any documents available.

Can I expect some more views on our situation? RA Experts please help

Thanks,
Manju
 
Last edited by a moderator:

sreenu927

Quite Involved in Discussions
#6
Hi Manju,

When there is a change in the existing software (FDA cleared!!), then you need to consider the following:
1. Has the intended use affected...so it's no in ur case.
2. Follow the FDA Guidance on 510(k) changes..which you already did.
3. re visit the risk assessment and where possible perform risk assessment for the changes affected...evidence in terms of updated of risk management report
4. perform s/w verification and validation withe new changes...evidence in terms of test reports.
5. check for any changes in labeling (indications for use-as u mentioned)?? Update your user documentation.
6. If your decision is just documentation (based on the above investigations, validation, risks), then while releasing your new software, perform a significant changes check (assuming that this is part of your procedures) and justify that there is no need to submit a new 510(k) for this software change and release the software.
7. File a "Letter to File or Memo to File" with the change description, justification into the Design History File or to 510(k) submission file.
8. Once you update the user documentation with the changes in "indications for use", then you must inform the customers through a Customer Advisory Notification or Customer Advisory Letter.

Regarding the types of 510(k), for your information, pls see below:

Traditional 510(k):
--devices or modifications to the existing devices
-- detailed requirements in 21 CFR 807.87
-- a minimum of 90 days for FDA review prior to introducing into commercial distribution
-- review can be longer (3-6 months)

Abbreviated 510(k):
-- device modifications when a guidance doc already exists
-- a special control has already been established
-- FDA has recognized a relevant consensus standard

Special 510(k):
-- for devices modifications that do not:
->affect the device intended use
->alter fundamental scientific technology
--minimum 30 days for FDA review prior to introducing into commercial distribution


I hope this helps.

Regards,
Sreenu
 
M

manju.ado

#8
Hi Sreenu,

Could you please further elaborate what route we should take for justifying the new 510(k) is not required?

As you mentioned in description of Special 510(K):

In our case changes to software & firmware will not affect the device indented use. These changes basically help us to improve the performance of the device, I don’t think it affects the intended use or am I interpreting the word indented for use wrongly. If I am interpreting correctly, then can we go for Special 510(k), if yes then what and all documentation we supposed to submit to FDA for approval?

Appreciate your help.

Thank you.

Regards,

Manju
 

sreenu927

Quite Involved in Discussions
#9
Hi Manju,

As you are stating the change is improving the performance, then it means it is affecting the performance and hence you need to decide whether to submit a special 510(k) or file a letter into DHF.

I suggest you to recheck the flowchart of "when to submit a change for 510(k)..." and take appropriate decision.

For a special 510(k), see the attachment.

Regards,
Sreenu
 

Attachments

Thread starter Similar threads Forum Replies Date
T First 510(k) submission - Class II software as medical device US Food and Drug Administration (FDA) 4
D Software as an accessory to a Class I medical device EU Medical Device Regulations 4
S Software Release Note - Class A stand alone software medical device IEC 62304 - Medical Device Software Life Cycle Processes 2
J Update Technical File for EU Class IIa Medical Software Products EU Medical Device Regulations 3
S Cloud-Based Stand Alone Software - Software Medical Device (Class II) US Food and Drug Administration (FDA) 2
K 510k "Premarket" Submission for Existing Class II Software Medical Device US Food and Drug Administration (FDA) 3
P UDI Registration - Class II Medical Device Software Other US Medical Device Regulations 10
K ISO 13485 requirements for Stand Alone Medical Device Software (Class II a) ISO 13485:2016 - Medical Device Quality Management Systems 1
S Can a medical software qualified as class III? CE Marking (Conformité Européene) / CB Scheme 1
T Class II Medical Device with Software - Change to Computer 21 CFR Part 820 - US FDA Quality System Regulations (QSR) 4
G How to certificate Class IIa Medical Device Software ISO 13485:2016 - Medical Device Quality Management Systems 5
W Question re: Class II Medical Device Software - Label / Device Definition Other US Medical Device Regulations 4
T Level of Concern for Class II Medical Device Software 510(k) Submission 21 CFR Part 820 - US FDA Quality System Regulations (QSR) 3
A Software Validation Requirements for Class I Active Medical Device EU Medical Device Regulations 4
R OEM and Labeling Issues - Class II Medical Device Software Other US Medical Device Regulations 1
D Off Label Usage (Class II Medical Device - Blood Bank Software) US Food and Drug Administration (FDA) 3
A Software Validation for Class I - Manufacture of a Part for a Medical Device ISO 13485:2016 - Medical Device Quality Management Systems 9
R Questions about 510k Class II Software Medical Device Other US Medical Device Regulations 10
P Class II Software Medical Device 510k Checklist 21 CFR Part 820 - US FDA Quality System Regulations (QSR) 6
K ISO 62304 Software Risk Management and Medical Device Class IEC 62304 - Medical Device Software Life Cycle Processes 5
S Data Management Software for Class II Medical Devices 21 CFR Part 820 - US FDA Quality System Regulations (QSR) 3
S Medical Device Labelling requirements for Class II software EU Medical Device Regulations 4
W Device History Record - Post Shipment - Class II Medical Device w/ Embedded Software 21 CFR Part 820 - US FDA Quality System Regulations (QSR) 6
E Any sample of a full software life cycle IEC 62304 report ( any class )? IEC 62304 - Medical Device Software Life Cycle Processes 1
N Validating Software before getting approved as Class 2 device US Food and Drug Administration (FDA) 5
L Radiology software Class I exemption Medical Device and FDA Regulations and Standards News 3
T Do I need a qualified compiler for class B software? IEC 62304 - Medical Device Software Life Cycle Processes 3
D Reduction of software class based on multiple external risk controls IEC 62304 - Medical Device Software Life Cycle Processes 5
B Class IIB Device - IEC 62304 Software Classification IEC 62304 - Medical Device Software Life Cycle Processes 13
I MDD Class I software technical documentation sample EU Medical Device Regulations 2
V Software as control or protection will lead to different Software Safety Class? IEC 60601 - Medical Electrical Equipment Safety Standards Series 18
B Software Class A - Lengthy further risk analysis IEC 62304 - Medical Device Software Life Cycle Processes 9
K ISO 13485:2016 Self Certification for Class I (annex 9) Stand-Alone Software? ISO 13485:2016 - Medical Device Quality Management Systems 3
B IEC 62304:2006/AMD1:2015 Changes for Class A Software IEC 62304 - Medical Device Software Life Cycle Processes 3
N Convert Class A Software to B by on-chip Watchdog IEC 62304 - Medical Device Software Life Cycle Processes 5
T Class II Software Device 510k V&V (Verification and Validation) Criteria and Results 21 CFR Part 820 - US FDA Quality System Regulations (QSR) 4
T 510k Submission - Class II Software communicates with a Non-Classified Device 21 CFR Part 820 - US FDA Quality System Regulations (QSR) 5
A Endoscopy Software - Class I or Class IIa or Class IIb CE Marking (Conformité Européene) / CB Scheme 4
BradM Class action lawsuit against Apple - iPod Software updates - 2006 thru 2009 After Work and Weekend Discussion Topics 2
S Data Management Software for Class II Devices 21 CFR Part 820 - US FDA Quality System Regulations (QSR) 4
T IEC 62304 & FDA: Software Development Methodologies for Class II- DICOM device IEC 62304 - Medical Device Software Life Cycle Processes 8
C Validation of Software - NIOSH product (Class II - N95 Respirators) ISO 13485:2016 - Medical Device Quality Management Systems 3
M CE requirement for software importer / reseller - Class II for FDA and Health Canada EU Medical Device Regulations 1
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) 2
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 4

Similar threads

Top Bottom