SBS - The best value in QMS software

IEC 62304 safety classification, External Controls and off-label use related risks

#1
We have some software in development.
Initially we weren't developing this software along 62304, but had performed some of the early 62366 use related risk anticipations to help place the product concept / use specification in less risky waters.
I am wondering about how, when and whether to count some of these in regard to 62304's software safety classifications.
Basically all of these early "controls" I'm considering were applied by limiting features and changing the intended use and indications for use. In 62366 speak they are applied all the way down at the use specification level.
The hazardous situations we workshopped would only arise and convert into harms with some gross, deliberate off-label misuse or use in the wrong environment(actually th wrong institution) and even then by breaking with institutional procedure.

Would a 62304 classification exercise take these preliminary, pre-user need controls into account? Are Off-label uses considered?
I expect the following:
Off-label misuse could ostensibly place software in C
On-label use places the software in A or B

How and what stages do people generally sensibly synergise their 62366 and 62304 processes?

Hope this makes sense and follows forum rules. I did look for an answer for a long time, I promise!
 
Elsmar Forum Sponsor

akp060

Involved In Discussions
#2
Hi, I need a bit more clarity for "controls" and "pre-user need controls".
Q1.
Are Off-label uses considered?
A. Yes, please see subclause 5.6.4 NOTE 1, fifth dashed-point
Q2.
How and what stages do people generally sensibly synergize their 62366 and 62304 processes?
A. For standalone software it would be the beginning of the product's lifecycle
For integrated software, it would be as soon as you begin specifying the technical requirements of the software

Let me know if anything remains unanswered. I would suggest simplifying the context of your questions especially the controls part, and the part you mention about limiting features, changing the intended use, and indications for use; the relevance of this part to the question is ambiguous for me.
 

Tidge

Quite Involved in Discussions
#3
The latest revisions to 62304 added some (important, IMO) nuance (*1) to software system safety classification. However, it should be recognized that areas of nuance are those where some potential issues can hide.

To answer this question, in the context of the latest revision of 62304...
Would a 62304 classification exercise take these preliminary, pre-user need controls into account? Are Off-label uses considered?
I expect the following:
Off-label misuse could ostensibly place software in C
On-label use places the software in A or B
... I think you should consider what functions you are actually allocating to software. I am assuming that this is not SaMD; if it is SaMD, all functions of the device are allocated to software, and as such if misuse leads to class C, then class C it shall be!

If the software has been allocated functions that can lead to the most serious harms, or if the software is intended to mitigate the most serious harms, then the software is almost certainly class C.

(*1) The nuance of 62304 (as I see it) is that now it is explicitly possible to allocate device functions to software that don't participate in the risk profile of a device in any meaningful way and not have to default to the most serious level of development effort (as if the software was "doing more"). This option was there previously, via software system decomposition, but under the previous revision it was always expected that there would be some level of software development commensurate with the risk profile of the finished product.
 
#4
Thanks akp060, Tidge, for your great answers.

Hi, I need a bit more clarity for "controls" and "pre-user need controls".
Yeah sorry, I was having difficulty figuring out how to explain this.

What I meant by this is that there was a very early Hazard Scenario brainstorming session which identified some potential use related risk scenarios.
In practice we decided to explicitly exclude certain environments and certain uses from the Indications for Use, Intended Use, and Use specification.... "Pre-User needs" really refers to the order that 62366 prescribes... This control was applied by rewriting the use specification.

As far as I can now see, the risk is mitigated so long as the product is not used in hospitals (it would have too be sold to a hspital for them to get it), and it's not used as a physiological monitor.

I don't see how I can estimate the risk there as the control was applied from the very beginning. I think it's exceedingly unlikely.

For these specific risks I don't see how there could be any feasible software based controls to further mitigate beyond interactive IFU, Instructions etc.

Let me know if anything remains unanswered. I would suggest simplifying the context of your questions especially the controls part, and the part you mention about limiting features, changing the intended use, and indications for use; the relevance of this part to the question is ambiguous for me.
The latest revisions to 62304 added some (important, IMO) nuance (*1) to software system safety classification. However, it should be recognized that areas of nuance are those where some potential issues can hide.

To answer this question, in the context of the latest revision of 62304...

... I think you should consider what functions you are actually allocating to software. I am assuming that this is not SaMD; if it is SaMD, all functions of the device are allocated to software, and as such if misuse leads to class C, then class C it shall be!

If the software has been allocated functions that can lead to the most serious harms, or if the software is intended to mitigate the most serious harms, then the software is almost certainly class C.
I would think these particular harms have been mitigated by restricting the customer base in this case.

Product is a software platform and a third party manufactured class II connected device. It's intended to be Non-device CDSS / Non-device MDDS in FDA view, but there is a desire to get a 62304 certification.

I suppose a qualitative risk estimation would show the likelihood of harm as exceedingly rare. There's no real way to quantify the risk of these particular misuses.

If the risk is exceedingly unlikely and the software wouldn't have a bearing...
 

Tidge

Quite Involved in Discussions
#5
Product is a software platform and a third party manufactured class II connected device. It's intended to be Non-device CDSS / Non-device MDDS in FDA view, but there is a desire to get a 62304 certification.

I suppose a qualitative risk estimation would show the likelihood of harm as exceedingly rare. There's no real way to quantify the risk of these particular misuses.

If the risk is exceedingly unlikely and the software wouldn't have a bearing...
62304 is a "development standard" rather than a "product standard"; the prescribed development activities of 62304 arise are determined by risk analysis. You can always take the approach of "We opted not to quantify the risk, so we treated the software as Class C for the purposes of development."

I personally don't want to make any suggestions (in an open forum, devoid of context) in the area of Clinical Decision Support Software. Over the past three decades, the pendulum has swung wildly, and the emergence of apps (as well as the weight of industry heavies behind them) has also had effects that I'm not convinced are settled. As we have witnessed with medical devices and procedures, attitudes can quickly shift.

I am more comfortable offering this piece of advice: If the software is designed to interface with an ME device, you should consider the cybersecurity implications/vulnerabilities to both the software and the device. The 14971 basis of 62304 doesn't exactly apply for non-physical harms (*1), but (medical device, medical software) developers can apply the prioritization concepts to cyber-security risks to drive appropriately thorough development processes as outlined in 62304.

(*1) I'm going to sidestep any discussion on whether or not a 14971-compliant, risk-based approach to medical device development could or should address all cybersecurity risks and simply state that it should be clear that regulatory authorities don't want these areas ignored.
 
#6
62304 is a "development standard" rather than a "product standard"; the prescribed development activities of 62304 arise are determined by risk analysis. You can always take the approach of "We opted not to quantify the risk, so we treated the software as Class C for the purposes of development."
I guess my issue is for these particular risks I'm not sure how to quantitatively estimate, since their controls/mitigants - some deliberately and some discovered on closer analysis of original product concept - were baked into the product concept from the start. So this is probably more of a 14971 and best practices question at this point, and not for this sub-forum. In these cases when drawn out puts our qualitative estimation of probablity very low. Any attempt at quantitative estimates will only make sense after test releases.

I personally don't want to make any suggestions (in an open forum, devoid of context) in the area of Clinical Decision Support Software. Over the past three decades, the pendulum has swung wildly, and the emergence of apps (as well as the weight of industry heavies behind them) has also had effects that I'm not convinced are settled. As we have witnessed with medical devices and procedures, attitudes can quickly shift.

I am more comfortable offering this piece of advice: If the software is designed to interface with an ME device, you should consider the cybersecurity implications/vulnerabilities to both the software and the device. The 14971 basis of 62304 doesn't exactly apply for non-physical harms (*1), but (medical device, medical software) developers can apply the prioritization concepts to cyber-security risks to drive appropriately thorough development processes as outlined in 62304.
This actually clarifies the issue greatly from a decision making perspective and bypasses my original quandry.

Once again, thank you, Tidge
 
Thread starter Similar threads Forum Replies Date
S Does IEC 62304 require documenting unresolved anomalies for all safety classes? IEC 62304 - Medical Device Software Life Cycle Processes 4
K IEC 62304 Amd 1 2015 - Figure 3 – Assigning Software Safety Classification IEC 62304 - Medical Device Software Life Cycle Processes 11
G Adopting old product - compliance with IEC 62304 IEC 62304 - Medical Device Software Life Cycle Processes 9
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
M IEC 62304 Software changes - Minor labeling changes on the GUI IEC 62304 - Medical Device Software Life Cycle Processes 3
K IEC 62304 - Testing Independance IEC 62304 - Medical Device Software Life Cycle Processes 5
K IEC 62304 - Functional and performance requirements for SOUP items IEC 62304 - Medical Device Software Life Cycle Processes 2
K IEC 62304 compliance - Code reviews as part of verification strategy IEC 62304 - Medical Device Software Life Cycle Processes 5
M Risk Analysis Flow - Confusion between ISO 14971 and IEC 62304 IEC 62304 - Medical Device Software Life Cycle Processes 8
D IEC 62304 Risk Classification - With and without hardware control IEC 62304 - Medical Device Software Life Cycle Processes 2
M IEC 62304 Class A Project IEC 62304 - Medical Device Software Life Cycle Processes 15
B Clause 5.1.12 of Technical Standard IEC 62304/A1 IEC 62304 - Medical Device Software Life Cycle Processes 5
P SOUP anomaly evaluation for MMA (Mobile Medical Application) IEC 62304 clause 7.1.3 IEC 62304 - Medical Device Software Life Cycle Processes 4
P IEC 62304 - evaluation of integration and system testing IEC 62304 - Medical Device Software Life Cycle Processes 4
P Risk acceptability alignment between ISO 14971 and IEC 62304 IEC 62304 - Medical Device Software Life Cycle Processes 6
D Required Checklist Showing Compliance to IEC 62304 IEC 62304 - Medical Device Software Life Cycle Processes 11
P Proposed revision of IEC 62304 - 2019 IEC 62304 - Medical Device Software Life Cycle Processes 6
S Relationship between IEC 62304 problem resolution and ISO 13485 IEC 62304 - Medical Device Software Life Cycle Processes 8
P IEC 62304:2006 A1:2015 - Software from the early 1990s IEC 62304 - Medical Device Software Life Cycle Processes 4
B IEC 62304:2015 vs IEC 62304:2006 + AMD1 IEC 62304 - Medical Device Software Life Cycle Processes 4
F IEC 62304 - Segregation and communication between software items IEC 62304 - Medical Device Software Life Cycle Processes 1
B Class IIB Device - IEC 62304 Software Classification IEC 62304 - Medical Device Software Life Cycle Processes 13
B IEC 62304 - Update Checklist IEC 62304 - Medical Device Software Life Cycle Processes 2
L Connection between IEC 62304 and Chapter 14 of IEC 60601-1 IEC 60601 - Medical Electrical Equipment Safety Standards Series 2
M IEC 62304 - Develop an Architecture for the Interfaces of Software Items IEC 62304 - Medical Device Software Life Cycle Processes 8
A SOP for software validation of software in medical device IEC 62304 IEC 62304 - Medical Device Software Life Cycle Processes 5
T I need to make test reports according IEC 62304 & IEC 62366 IEC 62366 - Medical Device Usability Engineering 2
D Changing software classification via software - IEC 62304 IEC 62304 - Medical Device Software Life Cycle Processes 3
D Software as risk control - Confused on one aspect of IEC 62304 IEC 62304 - Medical Device Software Life Cycle Processes 20
K Trying to figure out what satisfies a few aspects of IEC 62304 IEC 62304 - Medical Device Software Life Cycle Processes 2
Y IEC 62304 Section 4.3(a) - 100% probability of failure IEC 62304 - Medical Device Software Life Cycle Processes 3
Y Application of IEC/EN 62304 at an advanced stage of software development IEC 62304 - Medical Device Software Life Cycle Processes 4
T Is there any requirement to be compliant with IEC 62304 while implementing ISO 13485 ISO 13485:2016 - Medical Device Quality Management Systems 5
L Documentation Planning - IEC 62304 Clause 5.1.8 IEC 62304 - Medical Device Software Life Cycle Processes 2
C Software for Medical Devices - Requirements Content for compliance with IEC 62304 IEC 62304 - Medical Device Software Life Cycle Processes 1
W CPU BIST IEC 62304 - Embedded code has CPU instruction tests IEC 62304 - Medical Device Software Life Cycle Processes 2
K Risk Reduction by Risk Control: IEC:62304-Class C ISO 14971 - Medical Device Risk Management 15
C Per IEC 62304, are DHF documents Configuration Items? IEC 62304 - Medical Device Software Life Cycle Processes 5
P IEC 62304 AMD1:2015: What's new vs.the 2006 Edition? IEC 62304 - Medical Device Software Life Cycle Processes 4
F FDA PMK 510(k) - IEC 62304 Software Components Segregation Other US Medical Device Regulations 3
M IEC 62304 Applicability - GUI Control Software IEC 62304 - Medical Device Software Life Cycle Processes 3
B Our NB says that IEC 62304 is an ISO 14971 Requirement ISO 14971 - Medical Device Risk Management 1
B Clarification on interpretation of some EN ISO 14971:2012 & IEC 62304:2006 req's ISO 14971 - Medical Device Risk Management 46
H ISO 14971 vs. IEC 62304 vs. 98/79/EC vs. ISO 13485 (Software Medical Device) ISO 14971 - Medical Device Risk Management 1
D A desperate call for help - IEC 62304 software IEC 62304 - Medical Device Software Life Cycle Processes 5
B IEC 62304:2006/AMD1:2015 Changes for Class A Software IEC 62304 - Medical Device Software Life Cycle Processes 3
M IEC 62304, ISO 14971 and FDA Medical Device SW Guidance 21 CFR Part 820 - US FDA Quality System Regulations (QSR) 5
K IEC 62304 - Compliance steps IEC 62304 - Medical Device Software Life Cycle Processes 5

Similar threads

Top Bottom