Primary Operating Functions (POF) in IEC 62366-1:2015.

[Koskis]

Hi All,

I have a question related to your interpretation of the primary operating functions (POF) in 62366-1:2015.

Clause 3.11 specifies it as safety related and close to FDA's Critical Task term. However, in note 2 below - it then completely muddies the water by stating: " Note 2 to entry: The concept of SAFETY includes loss or degradation of performance resulting in an unacceptable RISK to the PATIENT, including USE ERROR that prevents the USER from effectively using the MEDICAL DEVICE to achieve its intended medical purpose. In IEC 60601-1, this is referred to as ‘essential performance’. .".

Also the definition part has examples like "series of display screens that the USER has to navigate through..."

...To me, 'Note 2', and definition part brings the POF closer to 2007 version's frequent functions. A lot of functions are related to effective use of the medical device, but not safety related.

What has been your take on the primary operating functions?

Br,
Koskis

 

[Ronen E]

A use error that gets in the way of the intended use ("prevents the USER from effectively using the MEDICAL DEVICE") is safety-related only if lack of delivery of that portion of the intended use poses an unacceptable risk to the patient (or the user, theoretically, but practically unlikely). Your risk analysis should spot these.

 

[indubioush]

The list in Annex A provide examples. The definition of "Primary Operating Function" is "function that involves USER interaction that is related to the SAFETY of the MEDICAL DEVICE." You must follow that definition. There is a reason why one of the examples is "series of display screens that the user has to navigate through." What they are saying here is that one primary operating function can consist of multiple essential steps. Let's take an example. Let's say a medical device is a heart monitor and the heart rate is displayed through a phone app. The user has to connect their phone wirelessly though bluetooth to the heart monitor. Now Grandma goes to her phone app, goes through a series of screens and tries to connect the bluetooth. But she doesn't understand where she is supposed to click. Setting up the bluetooth is essential for the device to function. She gives up because she can't figure it out. The device is unable to meet its intended purpose. She now goes into atrial fibrillation. The app would have called an ambulance automatically if it were set up correctly, but of course her phone app is not connected.

In this case, the primary operating function is the connection of the heart monitor to the patient's phone app, which required clicking through a series of screens.

 

[Koskis]

Hmm...I missed the reference to unacceptable risk also in the context of the effective use in the standard even though it clearly mentions that (like you describe). Big thanks for clarification - this is clear now!

 

[Koskis]

Further question about the clauses 5.2 to 5.5 asking to identify hazards and hazard related use scenarios

We have a software medical device product (IIa) and for clauses 5.2 (UI characteristics related to safety) and 5.3 foreseeable hazards we are referencing to risk file. In the CMT we have identified few user errors with potential hazard. However they are classified as "acceptable" - no RMR, nor Frequent. (I guess would not meet critical task criteria from FDA)

Is the expectation to still identify further 'hazardous scenarios' as per clause 5.4 even though risk is on acceptable level on the related foreseeable risks? If yes / no - what is the impact to the expectation for summative test for the product? So far the assumption has been that no summative test required due to reason mentioned in chapter above.

Thoughts?

 

[Tidge]

We have a software medical device product (IIa) and for clauses 5.2 (UI characteristics related to safety) and 5.3 foreseeable hazards we are referencing to risk file. In the CMT we have identified few user errors with potential hazard. However they are classified as "acceptable" - no RMR, nor Frequent. (I guess would not meet critical task criteria from FDA)

Is the expectation to still identify further 'hazardous scenarios' as per clause 5.4 even though risk is on acceptable level on the related foreseeable risks? If yes / no - what is the impact to the expectation for summative test for the product? So far the assumption has been that no summative test required due to reason mentioned in chapter above.

I can't speak for the expectations of an NB (or the FDA), but I expect some level of summative testing for the 'finished' device. My further expectation is that testing should be value-added. The risk files should make it evident where testing provides the most value. The text of 5.5 provides two choices: test all the hazard-related use cases or a subset of them based of the severity of the potential harm. If you did no summative testing it would be difficult to rationalize how you complied with the text of 5.5.

Specific to usability concerns: I'm assuming the hazardous scenarios have been deemed acceptable because of either (a) the a priori assessment of the risk was acceptable (i.e. you basically think the situation never occurs or never leads to a harm) or (b) you have identified or implemented specific elements in the UI to control the risks. For (a) you can leverage summative testing to either directly challenge the initial assessment and/or collect data via questionnaires to see if the initial assessment is correct (sanity test). I suppose it is possible that your specific UI implementation could have 'broken' the initial assessment by introducing some new risk. For (b), this would be a case that directly calls out for some level of summative testing to generate the objective evidence for the effectiveness of the risk control.