Software Class A - Lengthy further risk analysis

B

brentg

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
 
B

BhupinderSinghPawa

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?
 
B

brentg

[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]
 
B

BhupinderSinghPawa

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.
 
B

BhupinderSinghPawa

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?
 
B

brentg

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
 
B

BhupinderSinghPawa

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
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.
 
B

brentg

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
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.
 
Top Bottom