Use errors identification - based on primary operating functions or use scenarios ?

Hello,

I am working on the usability of a medical device software for the MDR transition.
I have a bit of a struggle to make the difference between "Primary operating functions " and Use scenarios.
In the sense that : when do we identify use errors ? From the primary operating functions ? The use scenarios ?
I don't understand why in the standard it seems that we first identify USE ERRORS (clause 5.2) before identifying the actual use scenarios / hazard related use scenarios (clause 5.4) ?
Personally, I would imagine defining the use scenarios first and then identify the USE errors related to it ?
Thanks for your help !

Primary Operating Functions should only occur during Use Scenarios; Use Scenarios can cover more ground than just the primary operating functions.

Practically, what I've done for medical devices is to have a "baseline" group of documents that provide initial assessments of (a) Hazards and (b) Patient Needs/Uses. These early docs are just to make sure we don't forget to consider certain hazards, and to not lose sight of what the device needs to do for a patient in the hands of a user... but there will typically be use cases that have nothing to do with the primary function of the device (e.g. cleaning or disposal).

From these documents I can construct a Hazard Analysis and a set of Use Cases, the Hazard Analysis is organized by Hazard, and each line of analysis (i.e. the risks) includes reference to the Use Cases where the Hazard can resolve itself into a Harm. The different Use Cases can result in different 'P1" (probability of being exposed to the hazardous situation); it is up to my teams if they want to to split the same line based on different P1s... sometimes they do (if the risk controls are different enough) and sometimes they don't (if they feel that the 'story' of acceptability will be clear enough without splitting).

Thank you for your response !
However, in the standard IEC 62366 there is no mention of the term "use cases". Is the "use cases" the term used in the US ?
what would be its equivalent in the IEC 62366 standard?
Thanks!

TomQA said:

Thank you for your response !
However, in the standard IEC 62366 there is no mention of the term "use cases". Is the "use cases" the term used in the US ?
what would be its equivalent in the IEC 62366 standard?
Thanks!

Click to expand...

A Use Case is essentially the TASKS (3.14), but it is not far from the USE SCENARIO (3.22), except that the way I handle use cases have a few subtle (or imagined!) differences.

(1) Often (especially for the NORMAL USE) I prefer to identify multiple classes (USER GROUPS) of USERS within a use case.

There will be different lines of risk analysis for the different users (based on different background, different mental models, e.g. USER PROFILES), but a strict textual interpretation of 62366-1 might imply more specificity than a developer would have if the diagram of 62366-2 (overview) would have you believe. I'm having trouble putting (what I see as) the distinction in words, but I generally feel that just as it isn't useful ab initio to presume precise and distinct HAZARDS, I feel that there would be more value from starting with more general Use Cases and then try to understand how the different USER GROUPS are likely to behave in the identified use cases. To me, I never explicitly create USE SCENARIOS, except that from the TASKS and USER GROUPS in the use case and the lines of analysis in the risk files the specific USE SCENARIOS are "obvious".

(2) The use cases include anticipated slips, lapses, mistakes, errors, and violations during task processing. 62366-1 has a catch-all term ABNORMAL USE for intentional actions and USE ERROR for everything else... but I think those terms in the standard are slightly loaded, and lead to arguments like: "The user didn't start out intending to use the device this way, but at some point they knew they were off-road and started taking actions they recognized as abnormal." The Annex D examples aren't at all bad, but "Abnormal" is somewhat in the eye of the beholder. "Who knew people would use cotton swabs to clean their ear canals?!"

(3) I find it easier to leverage use cases in the on-market phase of the life-cycle. YMMV, if the developers were usability-diligent it should just be an exercise in traceability to find the same information. A natural first question to ask in a complaint investigation is "what were you trying to do with it?" and go from there. It's not as if most users will know the precisely worded TASKS that are in a medical device manufacturer's usability file.

The terms "use case" appears in HE75, where it is attributed to "software engineers"! Maybe that is where I picked it up.