How do Functions & Tasks differ?

ThatSinc

Quite Involved in Discussions
Hi All,

I've been going back through the standard and trying to align the documents I have prepared earlier this year, but during discussions with other stakeholders there's confusion around terminology used and how the analysis flows.

3.11 * PRIMARY OPERATING FUNCTION
function that involves USER interaction that is related to the SAFETY of the MEDICAL DEVICE Note 1 to entry: Often a PRIMARY OPERATING FUNCTION is interacted with by a series of TASKS that can be broken down into a series of USER interactions. 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’. .

If a primary operating function is a function involving user interaction related to safety, then a function is any user interaction with the device to achieve a desired result.
Using the Primary Operating Function example of "– setting of infusion parameters (e.g. flow rate);"

How does this differ from a Task?

3.14 TASK
one or more USER interactions with a MEDICAL DEVICE to achieve a desired result Note 1 to entry: A TASK description should include the allocation of activities and operational steps between the USER and the MEDICAL DEVICE. Note 2 to entry: TASKS should not be described solely in terms of the functions or features provided by the MEDICAL DEVICE.


For analysis I'm looking to perform use-scenario task analysis, by breaking down functions into their subordinate tasks - this will allow the primary operating functions to be determined from the potential outcomes of use error if they are related to safety.

I appreciate that 62366 was originally intended for electromedical devices, being an IEC standard, and now is applicable to all devices - however the guidance in both the annexes and TR62366-2 is still heavily focussed on complex electromedical devices.



For a "basic" device, such as a single use, individually sterile packaged surgical blade, for attachment to a reusable scalpel handle;

To me the functions of the product are attachment to scalpel handle and cutting.

Would removal of the blade from the packaging be considered a function in its own right, a task within the function of attaching the blade to the handle, or a use step within the task of attaching the blade to handle, within a larger function?

If the user doesn't sanitise the sterile packaging before opening they could contaminate the blade
If the user doesn't open the sterile packaging from the correct end they could cut themselves on the blade easily
If the user can't grip the sterile packaging correctly they may not be able to open it safely at all.


Thanks,

TS.
 

adir88

Involved In Discussions
This definition of Primary Operating Function is updated in the 2020 amendment of IEC 62366-1. You might want to look at that first and come back to this topic.
 

ThatSinc

Quite Involved in Discussions
This definition of Primary Operating Function is updated in the 2020 amendment of IEC 62366-1. You might want to look at that first and come back to this topic.

Hi, the definition is the same, but indeed the clarification in Annex A that if product specific standards have called out primary operating functions you need to further assess them, otherwise simply work on identification of hazard related use scenarios.

That makes things a lot simpler (to some extent) in that I can essentially ignore the issue - I should be able to simply look at tasks, within use scenarios, and determine through analysis on each step of the task with regards to user interaction whether it could lead to harm.

But would still be good to clarify the confusion regarding functions and tasks.
 

Tidge

Trusted Information Resource
That makes things a lot simpler (to some extent) in that I can essentially ignore the issue - I should be able to simply look at tasks, within use scenarios, and determine through analysis on each step of the task with regards to user interaction whether it could lead to harm.

I don't think this is quite right. The following is written with no particular knowledge of the requirements of AED.

A common example cited of a device that had implemented an effective(?!) risk-control function that ran afoul of user tasks was an AED that implemented some sort of indicator that drew the attention of a user, but when the actions suggested by the indicator where followed the device was in a mode that prevented it from immediately being used in its primary purpose. Since the outcomes of AED application are highly correlated with the quickness of application, the delay introduced by the device function was catastrophic.

Perhaps another graybeard can provide the specific details of this case; I can't recall the specifics of that particular AED function, but it was something that would not have seemed out-of-place in an engineering context, but in a task-driven analysis it should have been obvious that the function was introducing an unacceptable level of risk.

In the case of the single-packaged blade, the design of the blade should be that it can be removed from the packaging (a user task) and inserted into the scalpel (another user task) such that the user doesn't cut themselves but still allows the blade to perform its primary function (cutting tissue). This is just analyzing one particular set of risks, there will be others as well.
 

ThatSinc

Quite Involved in Discussions
I don't think this is quite right.
I should have expanded; Ignore the confusion in terminology/semantics at my end, whilst still taking the context of the overall usage of the device in the tasks and use steps.
It solved the problem of following the intent of the standard, but doesn't solve my headache.

in a task-driven analysis it should have been obvious that the function was introducing an
unacceptable level of risk.
This is where I'd expect user testing to come into play, and the evaluation of whether control measures introduce new hazards or hazardous situations?


In the case of the single-packaged blade, the design of the blade should be that it can be removed from the packaging (a user task) and inserted into the scalpel (another user task) such that the user doesn't cut themselves but still allows the blade to perform its primary function (cutting tissue). This is just analyzing one particular set of risks, there will be others as well.

Okay, so I was off-base in my interpretation.

With the (former) examples from 62366 Annex A, where "setting of alarm limits" or "setting of infusion parameters" were listed as a primary operating functions, it seemed to me that the alarms or the infusion itself would be the functions, and the setting of them would be tasks. I took the examples as functions to be interactions with the device that can have a direct impact on safety - and thus started my headache.


Once again, you provide incredibly valuable insight. Thank you.
 

adir88

Involved In Discussions
Hi, the definition is the same, but indeed the clarification in Annex A that if product specific standards have called out primary operating functions you need to further assess them, otherwise simply work on identification of hazard related use scenarios.

That makes things a lot simpler (to some extent) in that I can essentially ignore the issue - I should be able to simply look at tasks, within use scenarios, and determine through analysis on each step of the task with regards to user interaction whether it could lead to harm.

But would still be good to clarify the confusion regarding functions and tasks.

My apologies. I did mean the description of PoF in Annex A.

In the example above, the function is "setting infusion pump parameter (flow rate)", but there are multiple tasks (or the way user interacts with the device) for this function: going through menu options and entering the value and confirming the value etc. Each interaction (whether these are physical buttons or options on a touch screen) is a task.

Now, if you device has a product specific safety standard and it says this particular function is a PoF, you just need to realize that the tasks related to this function are related to safety.

Hope this helps.
 

ThatSinc

Quite Involved in Discussions
Each interaction (whether these are physical buttons or options on a touch screen) is a task.

would you say each interaction, in terms of button presses or options on a touch screen is really an individual task, or would these be steps in the task of say "navigate to parameters page", then "Update Parameters", then "Confirm Parameters" as three tasks with the relevant button presses and options as steps in the task?
 

adir88

Involved In Discussions
It depends on how you're interpret it in your system. The definition of task is "one or more USER interactions" so you could make it a "group" task. However, note that if you take this approach, you still need to break these (group) tasks into "sub-tasks" for subsequent activities such as task analysis or PCA analysis.

It is clear from the standard that they want you to analyse each interaction with the UI and determine whether that can lead to a use error and hazardous situation, so keeping this in mind is important.

I strongly suggest that you read (or re-read) the following sections on this topic:

IEC 62366-1:
Annex A: 3.14 , 3.21, 3.22

IEC TR 62366-2:
9.2
Annex E: E.15, E.19
 

ThatSinc

Quite Involved in Discussions
you still need to break these (group) tasks into "sub-tasks"

I think we may be simply going over semantics on this, as per the definition of task and use scenario, a task can be made up of many steps, so to consider a task to be each isolated interaction wouldn't necessarily be the right thing to do.

To me;
Task - something you have to do
Task Steps - How you do it

It's interesting that 62366-1 doesn't make reference to sub-tasks at all, but they are referenced frequently in 62366-2

The hierarchy example in E.19 is very good, and shows sub-tasks and then steps within the sub-tasks - I can see how defining tasks and sub-tasks are beneficial in this respect.
It also includes tasks that are required to be performed, but not interactions with the UI - washing hands.


It is clear from the standard that they want you to analyse each interaction with the UI and determine whether that can lead to a use error and hazardous situation, so keeping this in mind is important.

Yes, this is very clear.
I haven't documented full PCA analysis, however as brainstorming activities during task analysis each task is assessed with PCA in mind.
 

ThatSinc

Quite Involved in Discussions
Wanted to circle back to this as I've been reading through both the standard and guidance more in depth and 62366-2 regarding FUNCTION ANALYSIS has a very clear and unambiguous statement in it

Functions allocated to USERS are called TASKS

With that in mind, for basic non-electrical devices with no level of automation, where all functions are performed by the user, would it be appropriate to state that all functions are tasks? But not all tasks are functions...
 
Top Bottom