Software Class A - Lengthy further risk analysis

#1
Hi All


I have been pruning info from this forum for some time now and am finally making the first post to see if any of you can help me out.


We are a Class IIa Medical Device have been CE & FDA certified since 2013 plus we are ISO 9001 and 13485 certified.


Our device is for providing oscillations the chest to product mucus in brief.


We do have 2 firmwares on the device one for display purposes the other to control. Since the conception we have classified ourselves as class A software for both.


Only in our very latest audit has this been brought into question and after lengthy further risk analysis still has one blocking point.


auditor argues that if the device failed to stop then the therapy would continue. My risk response of the microprocessor would stop the blower operating therefore cutting therapy was refused stating that a secondary hardware watchdog can only be used to mitigate that risk.


The acceptance of the Class A and our fully completed 62304 checklist has been fine for 5 previous audits yet trying to explain to this current auditor that our device wouldnt cause problems even if the therapy continued well past 20 minutes into 5 hours plus as it is extremely low background pressure andis more massage like is falling on deaf ears.


Any advice out there for my predicament other than buckle and go class B or C and increase the regulatory paperwork yet again :)


Many thanks


Brent
 
Elsmar Forum Sponsor

BhupinderSinghPawa

Involved In Discussions
#2
What is the recommended therapy time as per 'state of art' clinical protocols for the device?

What are contraindications?

Can user/patient set therapy time and the device automatically stops?

How does user (starts and) stop the therapy?

What are the likely harm to the patient should the software fail and device does not stop? This should be supported by clinical investigation - literature / clinical studies / predicate device / own experience. No harm / Non Serious Injury / Serious Injury - Death.

The mentioned risk mitigation (software based) is already implemented or proposed to be implemented?
 
#3
[FONT=&quot]Therapy Time
[/FONT]
[FONT=&quot]"Standard" Therapy time is 20-30 minutes.[/FONT]
[FONT=&quot]
[/FONT]
[FONT=&quot]Contra-indications
[/FONT]
[FONT=&quot]According to the American Association for Respiratory Care (AARC) Guidelines for Postural Drainage Therapy, the decision to use the Bronchial Clearance Device requires careful consideration and assessment of the individual patient’s case if the following conditions exist:[/FONT]
[FONT=&quot] [/FONT]
[FONT=&quot]Intracranial pressure (ICP) greater than 20 mm Hg[/FONT]
[FONT=&quot]Recent spinal surgery or acute spinal injury[/FONT]
[FONT=&quot]Bronchopleural fistula[/FONT]
[FONT=&quot]Pulmonary edema associated with congestive heart failure[/FONT]
[FONT=&quot]Large pleural effusions or empyema[/FONT]
[FONT=&quot]Pulmonary embolism[/FONT]
[FONT=&quot]Head and/or neck injury that has not yet been stabilized[/FONT]
[FONT=&quot]Active hemorrhage with hemodynamic instability[/FONT]
[FONT=&quot]Distended abdomen[/FONT]
[FONT=&quot]Active or recent gross hemoptysis[/FONT]
[FONT=&quot]Uncontrolled airway at risk for aspiration such as tube feeding or a recent meal[/FONT]
[FONT=&quot]Recent placement of transvenous or subcutaneous pacemaker (within 30 days)[/FONT]
[FONT=&quot]Recent epidural spinal infusion or spinal anesthesia[/FONT]
[FONT=&quot]Suspected pulmonary tuberculosis[/FONT]
[FONT=&quot]Lung contusion[/FONT]
[FONT=&quot]Bronchospasm[/FONT]
[FONT=&quot]Coagulopathy[/FONT]
[FONT=&quot]Complaint of chest wall pain[/FONT]
[FONT=&quot]Rib fractures, with or without flail chest (within 30 days – after this may help splint/stabilize)[/FONT]
[FONT=&quot]Surgical wound or healing tissue or recent skin grafts or flaps on the thorax[/FONT]
[FONT=&quot]Recent esophageal surgery[/FONT]
[FONT=&quot]Burns, open wounds, and skin infections on the thorax[/FONT]
[FONT=&quot]Subcutaneous emphysema[/FONT]
[FONT=&quot] [/FONT]
[FONT=&quot] [/FONT]
[FONT=&quot]Currently in the European market there are no norms or standards for HFCWO therapy, so we refer to the AARC Guidelines for the definition of Contraindications.[/FONT]
[FONT=&quot]
[/FONT]
[FONT=&quot]Therapy is started by using a touch screen interfact and stops by either using that to pause/stop or after therapy time finished.[/FONT]
[FONT=&quot]
[/FONT]
[FONT=&quot]Own experience for "proof" of no harm using for extended time[/FONT]
[FONT=&quot]small subset though - 5 people used for 2 hours on max[/FONT]
[FONT=&quot]Cannot prove wuth predicate devices as delivery mechanism is not the same.[/FONT]
[FONT=&quot]
[/FONT]
[FONT=&quot]All the migitgation is already implemented but not accepted as it is software based and auditor claims cannot be used for mitigation.[/FONT]
[FONT=&quot]
[/FONT]
[FONT=&quot]they quote[/FONT]
[FONT=&quot]
[/FONT]
[FONT=&quot]"If the device is microprocessor controlled, it means it does have software, which is the part of the microcontroller. If software is used to mitigate the risk, it means such software cannot be regarded as Class A anymore. Software class may be downgraded only if there is another hardware watchdog system implemented. "[/FONT]
[FONT=&quot]
[/FONT]
[FONT=&quot]
[/FONT]
[FONT=&quot]Brent
[/FONT]
 

BhupinderSinghPawa

Involved In Discussions
#4
As per EN 62304:2006/A1:2015 Section 4.3 Software Safety Classification, the Risk Control Measures (RCM) "external to" the Software System shall be considered - now this could be an hardware system or "another" software system.

The RCM software in your case - is it "independent" of the core "DEVICE" software? That is does it either runs on a separate processing unit OR even if it runs on same processing unit it has an independent process space? If yes, then it is 'external' to the 'device software system' and should be considered for lowering the 'device software system' risk classification.
 

BhupinderSinghPawa

Involved In Discussions
#5
The 62304:2006 states 'hardware risk control measure'.

The 62304:2006/A1:2015 states risk control measure 'external to the software system' - that can be hardware, independent software system, health care procedures etc.

Which revision of standard you are using?
 
#6
We are using standard 62304:2006/A1:2015


and in answer to your previous response - there are 2 separate microprocessors (pic32 & SSD) on 2 independant boards.




Thanks again for your responses


Brent
 

BhupinderSinghPawa

Involved In Discussions
#7
Software System 1 = Device Software
Let's say it can lead to Non Serious Injury, so (Class B)

Having implemented Software System 2 = Protection Software; that is 'external' to Device Software due to segregation on a separate processor

Software System 1 = Device Software, can be classified as (Class A)

Software System 2 = Protection Software to be classified as (Class B), as per 7.2.2 (b), that is based on the risk that the risk control measure is controlling

Overall Software System will be (Class B) the higher classification, with justification that the Device Software is Class (A) and Protection Software is Class (B).
 

mihzago

Trusted Information Resource
#8
the software risk classification is not directly based on the function of the software or its location in the system, but rather the harm it can cause to the patient.

The auditor's statement that the software cannot be regarded as Class A simply because it is a control measure is just wrong.

How did you classify the level of concern for the FDA submission? If this device required a 510(k) and is therefore likely a class II, I would be surprised if FDA allowed you to classify the software as a Minor Level of Concern.
While the FDA's classification is not the same as the one in IEC 62304, both are very similar, and in both, if the software can lead to non-serious injury, then you have to classify the software as B/Moderate.

So, go back to your risk assessment, and identify any hazards related to this piece of software or the risk of continued therapy. Can any of these hazards lead to non-serious harm? Again, focus on harm, not the failure or the probability.
If there is no harm to the patient, then you should be able to justify the software as Class A/Minor.
 
#9
For the 510(k) the software level of harm was - moderate.
Due solely to the fact of "Prior to mitigation of hazards could the software failure result in minor injury" which was yes.



I cannot argue that prior to mitigation (plus I was not the person who initially applied/got the 510k) minor injury could occur but was under the impression that the software classification for the 62304 can be with mitigation in place.


I have been back to the risk assessment, identified all possible hazards I could think of regards to continuation of therapy and still have none that lead to harm in my opinion.


I will resubmit this to the auditor and see where we end up.


Thanks everyone for your suggestions on this - superbly helpful.


Brent
 

mihzago

Trusted Information Resource
#10
For the 510(k) the software level of harm was - moderate.

I cannot argue that prior to mitigation (plus I was not the person who initially applied/got the 510k) minor injury could occur but was under the impression that the software classification for the 62304 can be with mitigation in place.



Brent

I forgot about the ability to reassess the risk after mitigations in the new version of 62304. However, the new version of the standard is not yet harmonized, so I'm not sure if you can use it.

Do you have other control measures for the uninterrupted therapy hazard? Or, did your software control measure reduce the risk from unacceptable to acceptable level, or was your risk for that hazard already acceptable, but you just included additional controls to comply with ISO14971 and "MDD deviations".
If that's the case, maybe you could use this as additional justification.
 
Thread starter Similar threads Forum Replies Date
T Do I need a qualified compiler for class B software? IEC 62304 - Medical Device Software Life Cycle Processes 3
T First 510(k) submission - Class II software as medical device US Food and Drug Administration (FDA) 4
D Reduction of software class based on multiple external risk controls IEC 62304 - Medical Device Software Life Cycle Processes 5
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
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
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 ISO 13485:2016 Self Certification for Class I (annex 9) Stand-Alone Software? ISO 13485:2016 - Medical Device Quality Management Systems 3
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 9
B IEC 62304:2006/AMD1:2015 Changes for Class A Software IEC 62304 - Medical Device Software Life Cycle Processes 3
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
N Convert Class A Software to B by on-chip Watchdog IEC 62304 - Medical Device Software Life Cycle Processes 5
W Question re: Class II Medical Device Software - Label / Device Definition Other US Medical Device Regulations 4
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
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 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
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
M Software for a Class II Medical Device - Required Advice for 510(k) 21 CFR Part 820 - US FDA Quality System Regulations (QSR) 10
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 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
S Medical Device Labelling requirements for Class II software EU Medical Device Regulations 4
C Validation of Software - NIOSH product (Class II - N95 Respirators) ISO 13485:2016 - Medical Device Quality Management Systems 3
W Device History Record - Post Shipment - Class II Medical Device w/ Embedded Software 21 CFR Part 820 - US FDA Quality System Regulations (QSR) 6
M CE requirement for software importer / reseller - Class II for FDA and Health Canada EU Medical Device Regulations 1
K Software Updates in the Field and ISO scope ISO 13485:2016 - Medical Device Quality Management Systems 0
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 3
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

Similar threads

Top Bottom